- Software definition:
- set of computer programs that when executed provide desired features, function and performance, 2) data structures that enable programs to adequately manipulate information and 3) documentation that describes the operation and use of the programs engineered/manufacture, wearsout/deterioties
1.1) SOFTWARE CRISIS: >proposed in 1968 conference to discuss software crisis >Software crisis is a term used in early days of computer science for the difficulty of writing useful and efficient computer programs in the required time. >software crisis resulted directly from the introduction of new computer hardware based on integrated circuits which had outpaced the ability of programmers to effecitely use those abilities as the required resulting software was orders of magnitude larger and more complex than previous software systems >Problems: complicated system, high quality, maintainalibity, voices to hear, failure to use engineering methods >Manifested itself in several ways: -Projects running over-budget -Projects running over-time -Software was vey inefficeint -Software was of low quality -Did not meet requirements -Were unmanageable and code difficult to maintain -Was never delivered >No silver bullet >Solution: need discipline, also adaptability and agility process
-
MEASURE OF SOFTWARE
PRODUCT QUALITIES: correctness and robustness (functionality) -is correct if it satisfies the functional requirements specifications, assuming they exist, while if specifications are formal corrected can be proved as a theorem or disproved by counterexamples -softare behaves resonably even in unforseen cirumstances, related with correctness usability (interface, aesthetics, friendliness) -that expected users find the system easy to use, rather subjective, difficult to evaluate, affected mostly by user interface: visual vs textual reliability (failure, severity of failures) -informally, user can rely on it, as probability of absence of failures for a certain period of time performance (speed, throughput, resoures consumption) -efficient use of resource: memory, processing time, can be verified using complexity analysis, simulation supportability (maintainability) -changes after release of software, consists of removing residual errors, adjusting to envrionemtnal changes, quality improvements understandability -ease of understanding softwaer, prgram modification requires program understanding, whether well documented and commented portability -software run on different hardware or software envirionments, remains relevant as new platforms and envrionemtns are introduced
ENGINEERING QUALITY: productivity (denotes its efficiency of process) timeliness (ability to deliver in time) visibilty (all of its steps and current status are documented clearly, transparency)
-
THE SOFTWARE PROCESS:
From bottom to top: qualtiy focus, (TQM: improving quality by having lowlevel workers to high ranking executives foucusing for customer satisfaction, CPI: ratio of earned value to actual cost) process, (framework for a set of key process areas) methods, (How to’s for builiding software for tasks like analysis, design, construction, testing) tools (automated or semi-automated support of the process, CASE)
DEFINITION:
Software process is an adaptable approach that provides collection of activities (communication with stakeholders), actions(architectural design) and tasks(conducting a unit test) that are required to develop a software system The generic software model identifies five framework activities universally applicable 1) Communication 2) Planning 3) Modeling 4) Construction 5) Deployment (framework same bhaye ni process farak huna sakxa)
complemented by umbrella activities (applicable in all phases, ongoing activities that do not lie in one particular phase) >Software project tracking and control >Risk management >Software quality assurance >Technical reviews >Measurment >Software configuration management >Reusability management >Work product preparation and production
Prescriptive models for process activities, actions and taks (do it) Agile models for adaptability and agility (solve it) …
5)Process model: prescribe a set of framework activities, actions, tasks and also a process flow- maner in which the process elements are interrelated to one another >linear, iterative, evolutionary, parallel
6)INSTANCES: (idea k ho ra interleaved kasari hunxan, pros and cons) i) Waterfall Model: >Work flow from communication through deployment is reasonably linear, becusae of the cascade from one phase to another, this model is known as waterfall >Principal stages: 1. Requirements defintion and analysis: The system’s services, constraints and goals are established by consultation with system users. They are then defined in detail and serve as a system specification. 2. System and software design; The systems design process partitions the requirements to either hardware or software systems. It establishes an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships 3. Implementation and unit testing: During this stage, the software design is realised as a set of programs or program units. Unit testing involves verifying that each unit meets its specification 4. Integration and system testing: The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer 5. Operation and maintenance Normally (although not necessarily) this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the system’s services as new requirements are discovered
>The following phase should not start until the previous phase has finished
PROS:
>when requirements are well defined and reasonably stable
>used for large sysem projects hwere a system is developed at several sites as the plan-driven nature of waterfall model helps coordinate the work
>documentaion is produced at each phase and that it fits with other engineering proess models
>a little elaboration (V-model)
CONS:
-Real projects rarely sequential flow
-Often difficult for the customer to state all requirements explicitly so only appropriate when the requirements are well-understood and changes will be failry limited
-A working version will not be available until late
-Bad utilization of resources (blocking states)
-Inflexible partioning of the project into distinct stages makes it difficult to respond to changing customer rquirements
ii) Evolutionary prototype:
>Based on the diea of devleoping an intial implementaion, exposing it to user commecnt and refining it through many versions until an adequate system has been developed so specification, development and validation activities are interleaved rather than separate, with rapid feedback across activities.
>Throwaway protoptyoe where objective is to understand the customer's requirements and hence develop a better requirements defiinton for the system. Exploratory development where the objective of the process is to work with the customer to explore their requirements and deliver a final system;
PROS:
-specificaiton are developed incrmenally as user develops a better understanding of their problem
-in producing systsems that meet immediate needs of customers
CONS:
-Process is not visible: maanger need regular deliverables to measure progress. if system is develoepd quicly it is not cost effective to produce documents that relfecte vey version of the styem
-System are poorly structured: as continual change tendds to correupt the software structure, incorporating software chagnes becomes increasingly difficult and costly
-customer thinks that it is a working version of the sofatware
-developer makes implementaion compromises to get a working prototype quiclkly
WHEN TO USE WHICH?
>For small and medium-sized systems (up to 500,000 lines of code), I think that the evolutionary approach is the best approach to development. The problems of evolutionary development become particularly acute for large, complex, long-life-time systems, where different teams develop different parts of the system.
>For large systems, I recommend a mixed process that incorporates the best features of the waterfall and the evolutionary development models
-This may involve developing a throwaway prototype using an evolutionary approach to resolve uncertainties in the system specification. You can then reimplement the system using a more structured approach
-Parts of the system that are well understood can be specified and developed using a waterfall-based process. Other parts of the system, such as the user interface, which are difficult to specify in advance, should always be developed using an exploratory programming approach
iii) Incremental models: (one of the exploratory prototype bhanna milxa)
>In an incremental development process, customers identify, in outline, the serivces to be provided by the system. They identfy which of the services are most important and which are least important to them
>Incremental delivery is an in-between approach that combines the advantages of both waterfall and prototyping model where the software specification, design and implementation are broken down into a series of incrtments that are each developed in turn.
PROS:
>Particularly useful when enough staffing is not available
>Increment can be planned to manage technical risks
>The cost of accommodating changing customer requirements is reduced than waterfall
> It is easier to get customer feedback on the development work that has been done
>More rapid delivery and deployment of useful software to the customer is possible
>Most impotant ssytem services receive the most testing.
CONS:
>INcrements should not be more than 20,000 lines of codes
>Process is not visible as managers need regular deliverables to measure progress, if systems are developed quickly not cost effective to produce documents that refelct every vesion of the sysem
>System structure tends to degrade as new increments ae added, as regular change tends to correupt structure and incorporating further software changes becomes difficualt
iv) Spiral developemnt:
>Using spiral mode, software is developed in series of evolutionary releases.
>The specification, development and validation are arranged around the spiral such that the first might result in the development of a product specificaiton, subsequent passes around the spiral might be used to devleop a prototype and then progressively more sophisitcated versions of the software.
>As this evolutionary process begins, the softwarevteam performs activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the center.
>as process progress, developer and customer react to risks at each level, for each identifies detailed analysis is carried out, steps are taken to reduce the risk, like if there is a risk that the requirements are inappropriate, a prototype system may be developed (risk risk gariraxa because meant for large systems)
PROS:
>The spiral model is a realistic approach to the development of large-scale systems and software
>Unlike other models, can be adapted to appply throughout the life of the softare
CONS:
>difficult to convince customers that its controllable
>requires considerable risk asessment expertise
>focuses on high quality rather than faster delivery or extensibility
>Has not been widely used as the linear orprototyping paradigms
SOME OTHER INSTANES:
V Model: A variation in the represntation of the waterfall model is called the V-model. It shows the relation betwen quality assurance actions to the communication, modelling and early construction activiites.
>As as software team moves down the left side of the V, basic problem requirements are reined into progressively more dteailed techinal representaions of the problem and its solution.
>Once code has been regenerated, the team moves up the right side of the V, essentially performing a series of tests that validate each of the models createsd as the team moved down the left side.
>Provides a way of visualitizng how verification and validation actions are applied to earlier engineering work
RAD Model:
>The rad model emphasizes on exteremely short development life-cycle.
>If requirments are well-understood and project scope is constrained, a fullly functional system canbe developed in very short periods
PROS:
>Business applications which can be modularized, each major function to be completed in less than 3months
>Each major function can be develpoed by a separate RAD team
CONS:
>Requires suffieint human resources to create the right number of RAD temas
>Requires specific teams
>Not appropriate when technical risks are high
STILL OTHERS HERE AND THERE
iv) Concurrent models:
>The framework acitivities exist concurrently but reside in different states ie change their states like (from awaiting to under revision to under review)
v) Specialized models:
>component based, formal methods, aspects based
vi) Unified process
>draw best features from classical and implement with best principle of agiles
-->(chck pcis)
>Planning by collaborating with customers to prepare basic architectures
>Elaboration refins and expands the use case developed in incepion
>Construction of necessary features
>Transition for later consturctiona and early deployement
>porudction is for deployment and monitoring to provide support
#same time const, transis, prod are being conducted, work for next software increment is started so phases occur with staggered concurrency
vii) Personal and team software process (create modesl that fit personal dveloper needs but also broader needs of organization)
>makes person repsonbile than adhoc methods
>Planning, high level design, high level reiew, development, postmortem
>requires commmitment and beat organizational inertia
OBSESSION WITH PROCESS IS DANGEROUS … COMPARISON:
(Waterfall, prototype, incremental, spiral, rad) Clear requirement specificaotn: intial level, medium level, initial, initial, initial Feedback from user: no, yes, no, no, no Spped to change: low, medium, high, high, no Risk identiifcation: at initial level, no, no, yes, no Understandibilty: Simple, intermiediate, intermediate, hard, intermideaite Cost: low, high, low, expensive, very high
COMPUTER AIDED SOFTWARE ENGINEREING: >s the name given to software used to support software process activities such as requirements engineering, design, program development and testing >CASE tools therefore include design editors, data dictionaries, compilers, debuggers, system building tools and so on >Uses/advantages: -Development of grahpicsl system models as part of requirements specification or the software design -Understainding a design using data ditionary that holds information about the entities and relations in a design -Generateion of user interfaces from a gaphical interface description that is created interactively by the user -Program debuggin through the rpvision of information about an executing program -Automated transmaltion of programs from an old version of a proramming language such as COBOL to more recent verison Eg: daigram eiditors, version managment systems, compilers, interpreters,
-
Requirement engineering:
broad spectrum of techniques and tasks that provide the appropriate mechanism for understanding what the customer wants analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system encompasses seven tasks: (can occur in parallel or adap;ted to the needs of the project)
CLASSIFICATION: 1. User requiremetns -mean high level abstract requirements and system requirements to mean the detailed description of what the sytem should do -are statements, in natural language plus diagram, of what sevices the system is expected to provide and the constraints under which it must operate -Readers: client managers, contractors, systen end-users
2. System requiremetns -detailed descripotno of what the system should do -set out the ystem's functions, services and operations contrainsts in detail. The system rquiement document (called functioanl speciiatno) shold be precise. -Readers: Softare developers, architects, end-users Eg: 1. LIBYS shall keep track of all data required by copyright licensing agencies in UK and elsewehre 1.1 On making a request for a document from LIBYS, the requestor shall be presented with a form that records details of the user and the rquest made 1.2 LIBSYS request forms shall be stored on the system for five years from the date of request 1.3 1.4 1.5 FUNCTIONAL AND NON: >Software system requirements are often classified as functional requirements, non-functional requirements or domain requirements (mathi ko chai functioanl huni bhayo) FUNCTIONAL: >statements of services the system should provide, how the system should react to partiular inputs and how the system should behave in particular situations >may be high level statements of what system should do in details >For LIBSYS: 1. The user shall be able to search either all of the initial set of databases or select a subset from it 2. The sysetm shall provide appropriate viewers for the user to read documents in the document store 3. Every order shall be allocated unique identifier which the user shall be able to copy to the acocont' permanent storage are. NON-FUNCTIONAL: >constraints on the services or functions offered by the system such as timing constraints, constaints on the development process, standard etc. >critical than functionals >response time and storage requirements >Non-functional requirements arise through user needs, because of budget constraints, because of organisational policies, because of the need for interoperability with other software or hardware systems, or because of external factors such as safety regulations or privacy legislation. >Types: -Product requirements: specify product behaviour like how fast the sytem must execute and how much memory it requiest -Organizsational: dervied from policies and procedures in custoner's and developer's organizsation. Process standards that must be used. -External: includes interoperability, legislatives, ethicals >Example: Prodcut requiremtn: 8.1 The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets Organisational requiremetn: 9.3.2 The system development process and delivralbes dcouments shall conform to the process and deliverales defined in xyzco..0df External requiremtn: 10.6 The system shall not disclose any personal information about the system users aprat from their name and library reference nubmer to the staff who use the systemSOFTWARE REQUIRMENTS DOCUMENT: >The software requirements document (sometimes called the software requirements specification or SRS is the official statement of what the system developers should implement. >t should include both the user requirements for a system and a detailed specification of the system requirement >The diversity of possible users from senior managment of the organizsation paying for the system to devlopers: means that the requirements document has to be a compromise between communicating the requirements to customers, defining the requirements in precise detail for developers and testers, and including information about possible system evolution. >Preface Introduction Glossary User requirements defiition (services provided fo rth user and non fucntions system requiremtns, could use natural language, diagrams or other notations) System architecture (overview) System requiremets specificaiotn (functional and non functional in detail) System models (might be relationships among componetns: data models,) System evolution Appendives Index
i) Inception: (Feasibility study) >business need is identified or potential market is discovered (scoping) >identify the stakeholders, recognize their multiple viewpoints, work towards collaboration and ask first questions >establish basic understanding of the problem, people who want solution, nature of the solution, effectiveness of communication between stakeholders and team >once scope is understood, analyse feasibility >Input to feasibiilty study is a set of preliminary business reuirements, an outline of description of the system annd how the system is intedned to support business processes >Result should be a reort that recommends whether or not it is worth carrying on with the requirements engineering and system development process -technical feasibility: >Is it technically posssbile? Is it within the state of the art? >Does the organization have the necessary resources? -economic >Can development be completed at a cost the software organization, its client, or the market can afford? -schedule >Can it be finished in acceptable time? Will the project’s time-to-market beat the competition? -operational >Is the problem worth solving, or will the solution to the problem work >How do the end-users and management feel about the problem/solution?
SAMPLE: 1. Introduction Overview Objectives Need Scope Deliverables 2. Feasibility Study Financial .. 3. Considerations 4. Referencesii) Elicitation And Elaboration (analysis) >Software engineers work with a range of system staekholdres and system end-users to find out about the application domain, what services the system should provide, reqiured performance of the system, hardware constraints and so on. >problems: -Stakeholders dont know what they really want except in most general terms or htey find it to difficult to articulate or make unrealsistic deamdnds -Requirment engineers, without experience in customers’ domain must udnertsnad their requirements -Different stakeholders have ddiferrent requirements, which they may express in different ways -New stakeholders may emerge and tehe business environment may change.
>Requirements elicitation and analysis is an iterative process with continual feedback from each activity to other activities. The process cycle starts with requirements discovery and ends with requirements documentation -requirements discovery >This is the process of interacting with stakeholders in the ssytem to colelct their requirements. You interact with stakeholders through interviews and observation. To be open-minded and avoid pre-conceived ideas about hte rquiremnts. Domain requirements from stakeholders and documentation of similar systems are also dicovered during this activity. -requirements classification and organization >Takes the unstructured collection of requirements, groups related requirements and organize them into coherent clusters -requirements prioritaization and negotiation >Where multiple stakeholdelers are invovled, reqirements will conflict, this activity is concerned with priotising areuqiments, and finiding and resolving requiremtn conflicts through negotiatin. Ask to balance functionaility, performance agains cost and time-to-market. Identify win-win conditon. -requirements specification >Requirements are documented and input into the next round of the spira. Formal or informal reuqimrent documents may be produced >can be a written document in natural language, structured natural language, design description languages, set of graphical notations, formal mathematical model, or combination of thesevi) Validation: >Concernted with showing that the requirments actually define the system that the customer wants and finding problems with the requiremetns >Is impornant beacuse errors in a requirments dcoument can lead to extensive rework >Validation techniques can be used in conjuction or individually: Requirements reviews requiremnts are analysed systematically by a team of reviewers -consistency checks -realism checks -completeness checks -verfiabiilty
Prototying an executable mdoel of the system is demonstrated to end users and customers, and they experiment with this model to see if it meets their real needs Test-case generation Requiements should be testable, if tests for requiemnts are devised as part of the valdiation process, this often reveals requiemnte problemsvii) Requirements management: >It is hard for users and system customers to anticipate what and how new effects the system as needs emerge. will have on the organisation. >Requirements management is the process of understanding and controlling changes to system requirements. >You need to keep track of individual requirements and maintain links between dependent requirements so that you can assess the impact of requirements changes. >Identified problem → problem analysis and change specification (if its valid) → change analysis and costing (whether to proceed) → change implementation (modify the changes) →revised requirements (FIG)
ANALYSIS AND MODELLING (SYSTEM MODEL OR ANAYSIS MODEL)
DOMAIN ANALYSIS >does not look at a specific applicaiton but rather at the domain in which the application resides with the intent to identify common problem solving elements that are applicable to all applications within the domain >eg like avionics to banking >domain analyst discovers analysis patterns and related information that may be used by many people working on similar but not necessarily the same applications
BUILDING ANALYSIS MODEL >representations that elaborate on basic requirements established during inception, elication and negotiations >on analysis results in specification of software’s operational characteristics, indicates software’s interface with other system elements, and establishes constraints that software must meet >hence analysis models bridges the system description and design model (PICS)
i) Context Models (context, and sometimes activity)
ii) Interaction Models (use case, activity, swimlane, sometimes sequence)
iii) Structual models (class complemented by crc)
iv) Behavioral model (DFD’s, sequence diagrams :: state)
v) Data modeling (ERD’s)
STRUCTURED METHODS: >A strucuted method is a systematic way of producing models of an existing system or of system that is to be built. >Most structured methods have their own preferred set of system models. They usually define a process that may be used to derive these models and a set of rules and guidelines that apply to the models >Weakness: -do not provide effective support for understanding or modelling non-funcitoanl system requirements -do not usually include guideliness to hlep users decide whether a method is appropraite for a particular problem -Often produce too much documentation -Models produced are detail oriented, users often find tehm difficult to understand so users cannot check realism
FORMAL SPECIFICATION: (speecificaiotn after architeceture) >formal specification is an excellent way of discovering specification errors and presenting the system specification in an unambiguous way. >increainsg in area of critical systems development where emergent system properties such as safety, reliabiilty and security are very imporatnt. >If formal specificaiton of the softare is developed, this usually comes after the system requirements have been specified but before the detailed high level system design. >The final stage of the process, which is the construction of complete, consistent and precise sepcificaiton, is princiaplly intented for the software contrarctor as it specifies the details of system implementation
WHY?
-Creating a formal specification forces you to make a detailed systems analysis that usually reveals errors and inconsistencies in the informal requirements specification
-specification problems discovered during formal analysis might influence changes to the requirements specification if this has not already been agreed.
-Developing and analysing a formal specification front loads software development
costs. With formal specification, specification and implementation costs are comparable, and system validation costs are significantly reduced
>IMPORTANT FIGURE SEE HERE
ARCHITECTURE DESIGN >Since programs are divied into modules, initial design process of identifying these sub-systems and establishing a framework for sub-system control and communication is called architectural desig >The architectural design process is concerned with establishing a basic strcutural framework that identifies the major components of a system and the communication between these components >They architecture may have to be designed before specifications are written to provide a means of structuring the specification and developing different subsystem specifications concurrently, to allow manufacture of hardware by sub-contractors and to provide a model for system costing
>Advantages:
->Stakeholder communication
The architecture is a high level presentation of the sytem that may be uased as a used as focus for discussion by range of stakehodlers. (so as to prepare formal specification)
->System analysis:
Architectural design decisions have profound effect on whether the system can meet critical requriements such as performance and reliability.
->Large-scale reuse
The system architecutre is often the same for systems with similar requirements and so can support large scale software reuse. Product-line architectures may be developed
->Modular decomposition:
Consititutes a relatively small, intellecualy graspable mode of how system is structure and how its components work together
ARHICTECTURAL DECISIONS:
>The system architecture affects the performance, robustness, distributalitya and maintainlity of a system. so particular style and structure chosen for an application may therefore depend on non-functioanl system requirements:
1. Performance: if is a critical requirement then architectura should be designed to localize critical operations within a small number of (large) components with these components all deployed on the same computer rather than the distributed network. Means using relatively large grain rather than fine grain components to reduce component communicaitons
2. Maintainability: if then should be designe dusing fine-grain self contained componentes that may readily be changed. A contradicting as using large components imporves perforances and using small fine -grain improve smaintainability
3. Security: if is then a layered structure for the architecure should be used, with most critical assests protected in the innermost layers with a high level of security validation applied to these layers
4. Safety: if is then all safety-related operations are localized in either a single component or in a small number of components
5. Availability: if is the architecture should be designed to niclude redundand components so it is possible to replace and update them without stopping the system
ARCHITECTURAL VIEWS:
>There aer four fundamental architectural views, which are related using use cases or scenarios
1. A logical view: shows key abstraction in the system as objects or boject classes, it should be possible to relate the system requiremetns to entitites in this logical view
2. A process view: shows hot at run-time the system is composed of interacting processes, useful for making judgement about non functionsal characteristics
3. A developmental view shows how software is decomposed for development ie shows the breakdown of the software into components that are implemented by a single developer, useful for software managers and programmers
4. A physical shows the system hardware and how software components are distributed across the proessors in the system, useful for software engineers planning a ssoftwaer deployment
5. Related using use scenarios (+1)
CHITECTURAL PATTERNS (SYSTEM ORGANIZATION): >stylized, abstract description of good practice which has been tried and tested in different systems and environments. Three organizational sytles that are very widely used. >Example is the MVC a
1)Layered architecture: (FIG)
>System functionality is organized into separate layers, and each layer only relies on the facilities and services offered by the layer immediately beneath it
PROS:
>Allows incremental software development
>Provides separation and independence.
>The architecture is changeable and portable. So long as its interface is unchanged, a layer can be replaced by another, equivalent layer.
>Only the inner, machine-dependent layers need be re-implemented to take account of the facilities of a different operating system or database
CONS:
>Clean sepration might be difficult
>Performance could be a problem as multiple layers passing needs ie a layer might need to punch through adjacent layers to get access to services that are provided several levels beneath it
2)Repository architecture (FIG)
>The layered was the conceptual organization while repository desscribes how a set of interacting components can share data.
>All data in a system is managed in a central repository that is accessible to all system components where they do not interact directly only through repository.
PROS:
>Components can be independent they do not need to know the existence of other comopnents so changes can be made independently.
>All data can be managed consistently such as backups done at the same time
CONS:
>Repository is a single point of failure so problems in the repository afffect the whole system
>May be inefficiencies in organizing all communication through the repository as they must agree on the common protocol.
>Evolution may be difficult due to lare volume of informatio generated
>Distributing the repository across several computers may be difficult
>Majority of sytems that use large amounts of data are oraganised around a shared database
3)Client-server architecture (FIG)
>The repository pattern is concerned with the static structure of a system and does not show its run-time organization
>A system that follows the client–server pattern is organized as a set of services and associated servers that offer those services, and clients that access and use the services.
PROS:
>Client–server architectures are usually thought of as distributed systems architectures but the logical model of independent services running on separate servers can be implemented on a single computer.
>Independence
CONS:
>Each service is a single point of failure
>Performance may be unpredectible as it depends on network
>May be management problems if servers are owned by different organizations
4)Pipe-filter architecture (FIG)
>A model of run-time organization of a system
>The functional transformations process their inputs and produce outputs, so data flows from one to another and is transformed as it moves through the sequence.
PROS:
>Can use implemented by combining Unit commands, using pipes and control facilities of the Unix shell
>Easy to understand and supports transformation reuse.
>Evolution by adding transformations is straightforward.
>Can be implemented as either a sequential or concurrent system.
CONS:
>Format for data transfer has to be agreed upon between communicating transformations
>Graphical user interfaces are hard to translate into a form compatible to pipelining model
5)Many other application specific architectures
MODULAR DECOMPOSITION STYLES:
>No rigid distinction between system organisation and modular decomposition but the components in modules are usually smaller than sub-systems, which allows alternatie decomposition styles to be used.
>Two strategies to decompose a sub-system into modules:
1. Object-oriented decomposition: where you decompose a system into a set of communicating objects.
PROS:
>Objects loosely coupled with well defined interfaces so their implementeaion can be modified without affecting other objects
>Objects are often representations of real-world entities so the structure of the system is readily understandable
>Easily available languages
CONS:
>To use services, objects must explicitly reference the name and the interface of other objects
>If an interface change is required to satisfy proposed system changes, the effect of that change on all users of the changed object must be evaluated.
>Some complex entities hard to represent as objects
2. Function-oriented pipelining: where you decompose a system into functional modules that accept input data and transform it into output data.
PROS:
CONS: (pipe and filter)
CONTROL STYLES
>The models for structuring a system are concerned with how a system is decomposed into sub-systems but to work as a system, sub-systems must be controlled so
that their services are delivered to the right place at the right time >Two generic control styles:
1. Centralized control
>One sub-system has overall responsibility for control and starts and stops other sub-systems. It may also devolve control to another sub-system but will expect to have this control responsibility returned to it.
>Centralised control models fall into two classes, depending on whether the controlled sub-systems execute sequentially or in parallel.
i. The call-return model
This is the familiar top-down subroutine model where control starts at the top of a subroutine hierarchy and, through subroutine calls, passes to lower levels in the tree. The subroutine model is only applicable to sequential systems
ii. The manager model
This is applicable to concurrent systems. One system com-ponent is designated as a system manager and controls the starting, stopping and coordination of other system processes where a process is a sub-system or module that can execute in parallel with other processes.
2. Event-based control
>Rather than control information being embedded in a sub-system, each sub-system can respond to externally generated events which might come from other sub-systems or from the environment of the system.
>Two event-driven control models:
i. Broadcast models
An event is broadcast to all sub-systems. Any sub-system that has been programmed to handle that event can respond
to it
ii. Interuppt-driven models
These are exclusively used in real-time systems where external interrupts are detected by an interrupt handler. They are then passed to some other component for processing
DOMAIN SPECIFIC ARCHITECTURES
>Common architectural structure common to a particular application domain
>Generic models are abstractions from a number of real systems and which encapsulate principle characteristics of these systems. For example, in real-time systems, there might be generic architectural models of different system types such as data collection systems or monitoring systems.
>Reference models are more abstract idealised model which are a way of informing designers about the general structure of that class of system.
Eg: OSI Reference model, Case reference model, ECMA reference model
DISTRIBUTED SYSTEM ARCHITECTUERS >Distributed system is a system where the information processing is distributed over several computers rather than confined to a single machine. A distributed system therefore requires software that can manage the diverse parts, and ensure that they can communicate and exchange data. >Generic types of distributed systems architectures:
1. Multiprocessor architectures:
>The simplest model of a distributed system is a multiprocessor system where the software system consists of a number of processes that may (but need not) execute on separate processors
>Using multiple processors improves the performance and resilience of the system. The distribution of processes to processors may be pre-determined (this is common in critical systems) or may be under the control of a dispatcher that decides which
process to allocate to each processor. >Common for large real-time systems, these systems collect information, make decisions using this information and send signals to actuators that modify the system’s environmenet
2. Client-server architectures
>The system may be thought of as a set of services that are provided to clients that make use of these services. Servers and clients are treated differently in these systems
>(As earlier)
>Simplest client-server is a two-tier client-server where an application is organised as a server (or multiple identical servers) and a set of clients. Can take two forms
i. Thin-client model:
>In a thin-client model, all of the application processing and data management is carried out on the server. The client is simply responsible for running the presentation software
>Where a device runs just a web-browser for interface
CONS:
>Places a heavy processing load on both the server and the network as server generates significant network traffic between the client and the server.
>There is a lot of processing power available in modern computing devices, which is largely unused in the thin-client approach.
ii. Fat-client model:
>In this model, the server is only responsible for data management. The software on the client implements the application logic and the interactions with the system user
>ATM where server is running customer account database
CONS:
>System management is more complex
>If application software has to be changed, involves reinstallation on every client computer
>The problem with a two-tier client–server approach is that the three logical layers—presentation, application processing and data management—must be mapped onto two computer systems—the client and the server which are solved by the three-client server
>Eg: Internet banking system
>The bank's customer databse (usually hosted on a mainframe computer) provides data management services; a web server provides the application services such as facilites to transfer cash, generate statements and paybills; and user's own computer with an Internet browser is the client.
>In some cases, it is appropriate to extend the three-tier client–server model to a multi-tier variant where additional servers are added to the system. Multi-tier systems may be used where applications need to access and use data from different
databases.
3. Distributed object architectures
>There is no distinction between servers and clients, and the system may be thought of as a set of interacting objects whose location is irrelevant. There is no distinction between a service provider and a user of these services
>A more general approach to distributed system design is to remove the distinction between client and server and to design the system architecture as a distributed object architecture where the fundamental system components are objects that provide an interface to a set of services that they provide, other objects call on these sevices with no logical distinction between a client (a receiver of a service) and a server (a provider of a service).
>Objects may be distributed across a number of computers on a network and communicate through middleware where the middleware is called an object request broker whose role is to provide a seamless interface between objects.
Advantages:
-Therefore, the distinction between fat- and thin-client models becomes irrelevant, as there is no need to decide in advance where application logic objects are located, ie system designer can delay decisions on where and how services should be provided
-It is a very open system architecture that allows new resources to be added to it as required as there are object communication standards have been developed and implemented.
-The system is flexible and scalable. New objects can be added as the load on the system increases without disrupting the other system objects
-It is possible to reconfigure the system dynamically with objects migrating across the network as required
>An example of a type of system where a distributed object architecture might be appropriate is a data mining system that looks for relationships between the data that is stored in a number of databases. An example of a data mining application might be where a retail business has, say, food stores and hardware stores, and wants to find relationships between a customer’s food and hardware purchases
MIDDLEWARE:
>The components in a distributed system may be implemented in different programming langugaes and may execute on completely different types of processor, models of data, information representation and protocols for communication may all be different
>Middleware is software that can manage these diverse parts, and ensure that they can communicate and exchange data.
>Provides :
1. Platform services that allow components written accordint to the model to communicate
2. Support services that are application-independent services used by different components to ensure that user of component services is authorized.
>CORBA provides services that enable reusable components to communicate with other components, regardless of their location within a system
>COM provides specification for using components produced by various vendors within a single application running under the Windows operating system
>Sun JavaBeans encompasses a set of tools
INTER-ORGANISATIONAL COMPUTING:
>For security and inter-operability reasons, most distributed computing has been imiplemented at the enterpirse level while newer models of distributed computing have been designed to support inter-organisational computing where different nodes are located in different organisations
1. Peer-to-peer architectures:
>Decentralised systems where computations may be carried out by any node on the network and, in principle at least, no distinctions are made between clients and servers and the overall system is designed to take advantage of the computational power and storage available across a potentially huge network of computers
>In semi-decentralised, the role of a server is to help establish contact between peers in the network, while once these are discovered, direct communications can be established and the connection to the server is unncessary.
2. Service-oriented architectures:
>Based on the notion of externally provided services, the web serices which ae standard approach to making a reusable component available and accesible across the web
>Services are based on agreed, XML-based standards so can be provided on any platform and written in any programming language.
>Key standards: SOAP (Simple Object Access Protocol)
Real-time software design:
>Embedded real time software reacts to events generated by the hardware or the environment and issue control signals in response to these events in real time
>Real time: a software system where the correct functioning of the system depends on the results produced by the system and the time at which these results are produced.
>Soft realtime:
-A system whose operation is degraded if results are not produced according to the specified timing requireents.
-Donot fail if deadline is missed, may degrade their service quality.
-Eg: Microphones, audio system (lag is undesirable but not catastrophic)
>A hard time:
-A system whose operation is incorrect if results are not produced according to the timing specificaiton.
-Missing deadlines is considered a system failure
-Eg: airplane sensors and autopilot systems
SYSTEM DESIGN CONSIDERATIONS: (FIG)
>One way is to look real system as a stimulus/response system. Given a particular input stimulus, the system must produce a corresponding response
>The generality of stimmulus response model of a reatime system leads to a generic abstract archtectural model where there are three type of processes. For each type of sensor, there is a sensor management process; computational process compute the required response for the stimuli received by the system; actuator control processes manage actuator operations
1. The topdown process where the design starts with an abstract that is decomposed and developed in series of stages is impractical for most real time systems as low level decisions on hardware, suppport software and system timimg must be considered in early in the process.
2. Real time systems are normally designed as a set of conrurent, cooperating process. To support the management of these processes, the execution platform for most real-time operating systems include a real time operating system.
3. State machine models are a good, language independent way of representing the design of a real time system as state model assumes that, at any time, the system is in one of a number of possible states.
i) Identify the stimuli that the system must process and associated respoonses
ii) For each stimuli and associated reponse, identify the timing constarants that applly to both stimulus and reponse processing
iii) Choose an execution platform for the system: hardware and the realtime OS to be used. Factors influecing these choices include timing contrainsts, power avaialb,e developement experience
iv) Aggregrate the stimulus and resposne processing into a number of concurrent processes. Is to associate a process with each class of stimulus and response.
v) For each stimulus and reponse, deisgn algorithms to carry out the required computations.
vi) Design a scheduiling system that will ensure that processes are started in time to meet their deadlines
Monitoring and control systems: (FIG)
>A class of realtime sytem that check sensors providing information about the systems envirionment and take actions depending on the sensor reading.
>Monitoring systems take action when some exceptional sensor value is detected. Control systems continuously control hardware actuators depending on the value of associated sensors
>Eg: Burglar alarm system with two type of stimuli (one power and another intruder) where constraints are:
>Sensors/Stimulus
Power fail interrupt
Door sensor
Window sensor
>Actuators/Response
Audible alarm
Lights switch
Communications
>Timing constraint
Data acquisition systems: (FIG)
>Sensors collect lots of data from the system's environment and it is not possible or necessary to process the data collected in real time so ensures that the sensor reading is collected before the snesor value changes so following architecture
>Used in scientific experiments and process control shstems where physical processes such as a chemical reaction, happen very quickly, neutron flux sensor
>In real time systemss the execution speeds and periods of the acquisition process (producer) and the processing process (consumer) may be out of step.
>If only simple computations need to be carried out, the processing may be faster than data acquisition. While if signifcant processing is reuqired the data acquisition may go faster than the data processing.
>To smooth these speed differences, the data acquisition systems buffer input data using a circuilar buffer, the process producing the data (producer) adds informaiton to this buffer, and the process using the data takes informaiton from the buffer.
>MUTUAL EXCLUSION must be implemented to prevent the producer an consumer processes from accessing the same element in the buffer at the same time. Also that producer does not add data to full buffer and sconsumer does not take from empty one.
Real-time OS: (FIGURE)
>A RTOS handles and allocates memory and processor resources so that stimuli can be handled. They usually include:
i) A real time clock: provies information to schedule processes periodically
ii) An interrupt handler that manages aperiodic requiest sevvice
iii) A scheduler: reponsible for examining the processes that can be executed and chossing one of these for execution
iv) A resource manager: given a process allocated, provides appropriate memory and processor resources
v) A despatcher: responsible for starting the executionof a process
>Real-time operating systems for large systems, such as process control or telecommunication systems, may have additional facilities, such as disk storage management and fault management facilities, that detect and report system faults and a configuration manager that supports the dynamic reconfiguration of real-time applications
>Sometimes processes take priority:
-Interrupt level: Highest priority which is allocated to processes requiring a very fast response
-Clock level: Allocated to periodic processes
>Scheduling strategies:
-Non pre-emptive: Once a process has been scheduled for execution it runs to completion or until it is blocked for some reason.
-Pre-emptive: The execution of an executing process may be stopped if a higher-priority process requires service.
DIFFERENCES:
Completion time critical: Not
Always active and sampling: Only busy when work is assigned
Normal computer specification: High hardware specification
Cant use virtual memory: Can use one
Flat memory model: Protected memory model
Less multitasking: Allows multitasking
Complex scheduling algorithm: Not so
SOFTWARE REUSE: >A comparable software engineering strategy where the development process is geared to reusing existing software >Software units that are reused may be of radically different sizes, from applications to whole systems
Benefit:
>Accelerated development:
Bringing a system to market as early as possbile is oftern more important than overall development costs. Reusing can accelerate developent and validation time
>Increased dependability
Reused sofware which has been tried and tested in working systems, should be more dependable than new software because its design and implementation faults have already been found and fixed
>Reduced process risk:
Cost of existing software is known, which reduces margin of error in cost estimation. Particuarly true when relatively large software components are used
>Effective use of specialists:
Instead of doing the same work over and over, these application specialists can develop reusable software that encapsulates their knowledge
>Standard compliance:
Some standards, such as user interface standards, can be implemented as a set of standadrd reusable components. For eg. if menus in a user interface are implemented using reusable components, all applications present the same menu formats to users
Problem:
>Increased maintence cost:
If the source code of a reused software is not available, then maintainence cost may be increased because the reused elements may become increasingly incompatible with system changes
>Lack of tool support:
Case toolsets may not support development with reuse. It may be difficult to integrate these tools with a component library system. The software process assumed by these tools may not take reuse into account
>Not invented here syndrome:
Software engineer prefer to rewrite components, thinks they can imorve on them. Wiritng original software is seen more challening
>Creating and maintaining a component library:
Populating a reusable component library and ensuring the software developers can use this library can be expensive. Our current techniques for classifying and retrieinvg sfotware components are immature
>Finding, understanding and adapting resuable components:
Software components have to be discovered in a library, understood and, sometimes, adapted to components work in a new environment.
Key factors to consider:
>Development schedule for the software:
If software has to be devloped quickly, you should try to reuse off-the-shelf systems rather than individual components
>Expected software lifetime:
If you developing a long-lifetime system, you should focus on the maintainability of the system. In those cases, you should not just think about the immeediate but also long term implications of reuse. So if you dont have source code, you should avoid
>The background, skills and experience of the team:
All reuse technolgoies are fairly complex and you need quite a lot of time to understand and use them effectively. Therefore, if the development team has skills in a particular area, this is probably where you should focus
>The criticality of the software and its nonfunctional requirements:
If software has stringent performance requirements, it may be impossible to use strategies such as reuse through program generators.
>The application domain:
In some domains such as medicals, there are several generic products that may be reused by configuring them to a local situtaion.
>The platform on which system will run.
Some components models, such as COM are specific to microsoft.
REUSE LANDSCAPE:
>Range of possible reuse techniques:
1. Design patterns:
2. Application frameworks:
3. Program generators:
4. (system reuse) COTS integration:
5. (system reuse) Application product lines:
6. Component-based developent:
Systems are developed by integrating comopnents that conform to component-model standards
7. Legacy system wrapping:
Legacy systems that can be wrapped by defining a set of interfaces and providing acess to these legacy sysems through these interfaces
8. Program libraries:
Class and function libraries implementing commonly used abstractions are available for reuse
9. Aspect oriented Software develpment:
Shared component are woven into an application at different places when the program is compiled
10. Service oriented systems:
Systems are developed by linking shared service which may be externally provided
11. Configurable vertical applications:
A generic system is designed so that it can be configured to the needs of speciic system customers
DESIGN PATTERNS:
>Executable components constraints design so patterns provide description of the problem and the essence of its solutions which are sufficiently abstract to be reused in different settings
>Generic abstractions that occur across applications are represented as design patterns
>Four essential elements of design patterns:
-Name that is meaningful reference to the pattern
-A description of the problem area that explains when the pattern may be applied
-A solution description of the parts of the design soluton, their relationships and their responsibilities. It is a template for a design solution that can be instantied in different ways
-A statement of consequences the results and tradeoffs of applying the pattern
>Eg: Observer pattern:
Pattern name: Observer
Description: Separates the display of the state of an object from the object itself
Problem description: Used when multiple displays of state are needed
Solution description: The structure of the pattern (FIG)
Consequences: Optimisations to enhance display performance are impractical
APPLICATION FRAMEWORKS:
>Components too fine-grained so collection of abstract and concrete classes can be adapted and extended to create application systems
>A framework is a subsystem design made up of a colllection of abstract and concerete classes and the interface between them where the subsystem is simplemented by instantiating the abstract classes in the framework
>Application are normally construcuted by integrating a number of frameworks.
1. System infrastructure frameworks
Support the development of system infrastructures such as communications, user interfaces ad compilers
2. Middleware integration frameworks
Standards and classes that support component communication and information exchange. Examples include CORBA, microsoft COM+, java beans
3. Eterprise application frameworks
Support the development of specific types of application such as such as telecommunications or financial systems.
>Eg is MVC:
-System infrastructure framework for GUI design
-Allows for multiple presentations of an object and separate interactions with these presentation
-MC framework invovles the instantiation of a number of patterns
GENERATOR BASED REUSE:
>Possbile when domain abstraction or knowledge of a particular type of application and their mapping to executable fragment can be identified
>A program generator system captures the reusable knowledge and can be programmed by domain experts using either a domain-oriented language or tools.
>Examples:
-Parser generators for language processing
The generator input is a grammar describing the langauge to be parsed and the output is a language parser. This approach is embodied in systems such as lex and yacc of C programming language
-Code generators in CASE tools:
Input to these generators is a software design based on UML models and output is a program implementing the designed system.
APPLICATION SYSTEM RESUSE:
>Involves resuing entire application systems either by configuring a sytem for a specific envrionment or by integrating two or more system to create a new application.
1. COTS product reuse:
>COTS product is a software system designed for general use that includes many features and functions and that can be used without change by its buyer in different applications and environment.
>Virtually all desktop software and a wide variety of server products are COTS which have defined application programming integraces allow program access to system functions. Like an antivirus software
2. Software product lines:
>Product line is a set of applications with a common application-specific architecture where the common core of the application family is reused each time by implementing additional components when a new application is required.
>Various types of specialisation of a software product line may be developed on platform, environment, functional and process level. And configured at deployment or design time.
>A Enterprise Resource Planning (ERP) is a generic system that supports common business processes such as ordering and invoicing, manufacturing etc.
COMPONENT-BASED SE: >Designers’ frustration that object-oriented development had not led to extensive reuse, as originally suggested as single object were too detailed and specific, and often had to be bound with an application at compile time >CBSE is the process of defining, implementing and integrating or composing loosely coupled independent components into system.
COMPONENTS (FIG)
>A component is an independent software unit that can be composed with other components to create a software system according to a composition standard or another useful way is to think as a provider of one or more services.
>Components have two realted interfaces. These interfaces reflect the services that the component provides and the services that the component requires to operate correctly
i) Provides interface:
-Defines the services that are provided by the component to other components. This interface is the component of API.
-It defines the methods that can be called by a user of the component
ii) Requires interface:
-Defines the serices must be avaialble for the component to be executated as specified
-This does not compromise the independence or deploybiilty of component because the requires interface does not define how these services should be provided.
>Example: A Data collector components with
requires: sensorData
provides: report, list, startSensor, stopSensor
COMPONENT MODELS: (FIG)
>A component model is a definition of standards for component implementation, documentation, and deployment which are used by component developers to ensure that components can interoperate.
1. Interfaces:
Components are defined by specifying their interfaces. The component model specifies how the interfaces should be defined and the elements such as operaiton names, parameters and exceptions, which should be included in the interface definiiton.
2. Usage:
They need to have a unique name or handle associated with them for components to be distributed and accessed remotedly. Component meta-data is data about the component itself such as information about its interfaces and attributes which allows users of the comonents to find out what serices are provided and required. Customizaiton is also needed as components are generic entities and when deployed they have to be configured to fit into an application system.
3. Deployement:
The component model includes a specification of how components should be packaged for deployment as independent, executable entities.
CBSE PROCESS:
>Software processes that support component based software enineering by taking into account the possibilites of reuse and different process activiites invovled in developing and using reusable components.
1. Development for reuse
>This process is concerned with developing components or services that will be reused in other application which usually involves generalizing existing components with the objective is to produce one or more reusable components.
>You know the components that you will be working with and you have access to their source code to generalize them
>There is a trade-off between reusabliitly and usability: the mroe gneral the interface, the greatear the reusablliy but it is then more complex and hence less usable
2. Development with reuse
>This is the process of developing new application using existing components and services.
>You don’t know what components are available, so you need to discover these components and design your system to make the most effective use of them
>Supporing processes:
i. Component acquisition
Process of acquiring component for reuse or development into a reusable component. Involves accessing locally developed components or serivces or dining these components from an external source.
ii. Component management
Concerned with managing a company's resuable components, ensuring that they are properly cataloged, stored and made available for reuse.
iii. Component certification
Process of checking a component and certifying that meets it specification
DIFFERENCES:
1. Requirement:
Stakeholders are encouraged to be as flexible as possible in defining their requirements. If user requirement cannot be satisfied from available components, discuss the related requirements that can be supported.
2. Architecture:
Defining a robust architecture is critical for successful reuse so may choose a component model and implementation platform. There is a further component search and design refinement activity after the system architecture has been designed.
3. Development:
Development is a composition process where the discovered components are integrated.
COMPONENT COMPOSIITON (FIGS)
>Component composition is the process of integrating components with each other, and with specially written ‘glue code’ to create a system or another component
1) Sequential composition
>You create a new component from two existing components by calling the existing components in sequence.
>Can think of it as composition of the 'provides interfaces' where service offered by component A are called and the results returned by A are then used in the call to the services offered by component B.
2) Hierarchial composition:
>This type of composition occurs when one compnent calls directly on the services provided by another component. The called component provides the services that are required by the calling componnet.
>Therefore the 'povides' interface of the called componnet must be compatible with the 'require' omponent of the calling componenet
3) Additive composition:
>When two or more components are put together to create a new component, which combines their funcitnlairty. The provides interface and requries interface of new compoonent is a combinatino of the corresponding interfaces in components A and B.
VERIFICATION AND VALIDATION:
>V and V checks to ensure that the software meets it specification and delivers the functionality expected by the people paying for the software, which starts with requirement reviews and continues through design reviews and code inspections to product testing and to establish confidence that the system is fit for purpose
Validation: are we builidng the right product?
Verification: are we builiding the product right?
>Verification involves checking that software software conforms to its specification, both functional and non-functinal requirements
>Validation is more general general process which goes beyond showing that software does what customer expects it to do.
>Within V an V process there are two complementary approaches to checking and analysis
1. Software inspection or peer reviews
>Analyse and check system representations such as requirements document, design diagrams and the program source code.
>Are static V and V technique as you dont need to run the software on a computer
2. Software testing
>Involves running an implementaion of the softwaer with test data.
>You examine the ouputs of the software and its operation behaviour to check that it is performing as required
>The process of V and V and debugging are normally interleaved. As we discover faults in the program that you are testing, you have to change the program to correct these faults.
-V and V are intended to establish the existence of defects in a software system
-Debuggin is a process that locates and corrects these defects
PLANNING VERIFICAOIN AND VALIDATION:
>Start plannnig system validation and verifiacaiton early in the devlopment process.
>The V model shows that the test plans should be derived from the system specificaiton and design.
>As part of the V & V planning process, you should decide on the balance between static and dynamic approaches to verification and validation, draw up standards and procedures for software inspections and testing, establish checklists to drive program inspections and define the software test plan
>As a general rule, the more critical a system, the more effort should be devoted to static verification techniques
SOFTWARE INSPECTION:
>Software system is reviewed to find errors, omissions and anomalies, generally focuses on source code, but any readable representation of the software such as its requiremtns or a design model can be inspected.
>Carried out in a meeting by the team of Author or owner, Reader, Inspector, Scribe, Chairman or moderator, Chief moderator
>Advantages of inspection over testing:
1. Incomplete version of a system can be inspected without additional costs.
2. During testing, errors can hide other errors. Once once error is discovered you can never be sure if other output anomalies are due to a new error or are side effects of original error. While in inspection no interaction between errors
3. As well as searching for program defects, an inspection can also consider broader quality attributes of a program such as compliance with standards, portability and maintainability
4. Careful inspection can catch 40% errors, which can be extended to 90% if done systematically
>Steps:
1. Planning:
The inspection team moderator is responsible for inspection planning. This involves selecting an inspection team, organising a meeting room and ensuring that the material to be inspected and its specifications are complete.
2. Overiew:
The program to be inspected is presented to the inspection team during the overview stage when the author of the code describes what the program is intended to do.
3. Individual prep:
Each inspection team member studies the specification and the program and looks for defects in the code with a checklist which usually varies according to programming language
4. Inspection meeting:
Discuss on individual results and conduct team inspection
5. Rework:
Following the inspection, the program’s author should make changes to it to correct the identified problems.
6. Follow-up:
In the follow-up stage, the moderator should decide whether a reinspection of the code is required
>Checklists of common errors should be used to drive the inspection: initialization, constant naming, loop termination etc.
>Example of automated software inspection is PINT
FORMAL MODELS:
>Very detailed and mathematical analyses of the system specification and the program based on mathematical representations of the software, usually as a formal specification.
>ARUGMENt FOR:
1. It may reveal potential inconsistencies or omissions that might not otherwise be discovered until the system is operational.
2. Formal verification demonstrates that the developed program meets its specification so implementation errors do not compromise dependability
>ARGUMENT AGAINST:
1. Requires specialised notations which can only be used by specially trained staff and cannot be understood by domain experts.
2. Expensive and time-consuming for large systems
CLEANROOM:
>Well documented appraoch that uses formal methods to produce zero-defect software.
>Based on following strategies:
i. Formal specification
Mathematically specified requirements
ii. Incremental development
Partitioned into increments which are developed and validated separately
iii. Structural programming
Stepwise refinement of specifications with limited number of data abstracts and constructs
iv. Static verification
Statically verified using rigorous software inspections
SOFTWARE TESTING
>Testing has two goals:
1. Validation testing:
To demonstrate to the developer and the customer that the software meets its requirements which means that there should be at least a test for all of the system features incorporated in product release
2. Defect testing:
To discover faults or defects in the software where the behaviour of the software is incorrect, undesirable or does not conform to its specification.
>Examples: Selenium,
SYSTEM TESTING:
>Invovles integrating two or more components that implement system functions or freatures and then testing this integrated system.
>Two distinct phases:
1. Integration tesing:
>Integration testing is mostly concernd with finding defects in the system.
>Testing of system components which involves building a system from its components and testing the resultant system for problems that arise from component.
a. Top-down integration:
Overall skeleton of the system is developed first, components are added to it
b. Bottom-up integration:
First integrate infrastructure components that provide common services, such as network and database acces, then add the functional components
>Regression testing:
-To localise errors as there are complex interactions between the system components and when an anomalous output is discovered, hard to identify where the error occured or whether an iteraction with new component caused it. As a new increment is integrated, important to rerun the tests for previous incremnts as well as the new tests that are required to verify the new system funcionality.
2. Release testing:
>Test team is concerned with validating that the system meets its requirements and with ensuring that the system is dependable to increase the supplier's confidence that system meets its requirements.
>Release testing is usually black box (system is treated as a black box whose behaviour can only be determined by studying its inputs and the related outputs) testing where the test team is simply concerend with demostrating that the sytem does or does not work prorperly.
# Performance testing:
>Performance tests are designed to ensure that the system can process its intended load.
>Involves planning a series of tests, around the limits of the system, where the load is steadily increased until the system performance becomes unacceptable, i.e by making demands that are outside the specified capabilities of the system.
COMPONENT TESTING:
>Process of testing individual components in the system in isolaion to expose fualts in the system.
>Involves testing indivudual function or methods within an object, object classes that have several attributes and methods, composite components made up of several different objects or functions.
>Strategies:
>Testing in isolatin of all operations associated with the object
>Setting and interrogation of all attributes associated with the object
>Exercise of the object in all possible states which means that all events that cause a state change in the object should be simulated
USER TESTING:
>User testing is essential, even when comprehensive system and release testing have been carried out because influences frOm the user's working environment have a major effect on the reliablity, performance, usablity and robustness of the system.
>User or customer testing is a stage in the testing process in which users or customers provide input and advice on system testing.
1. Alpha testing:
Users of the software work with the development team to test the software at the developer’s site.
2. Beta testing:
A release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers.
3. Acceptance tesing:
Customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment. Primarily for custom systems.
TEST CASE DESIGN:
>Test case design is a part of system and component testing where you design the test cases (inputs and predicted ouputts) with the goal to create a set of test cases that are effective in discovering program defects and shwoing that the system meet its requiremetns
>Approaches
1. Requirement-based testing:
Test cases are designed to test the system requiremetns, used at system testing stage so requiresments should be writen in such a way that a test can be deisigned so that an observer can check that the requirement has been satisfed.
2. Partition testing:
-Programs tend to behave in comparable way for all members of a partition class such as all negative numbers, strings less than 30, so it involves identifying input and output partitions and design tests so that the system executes inputs from all partiions and generates outputs in all paritons.
-A good rule of thumb for test case selection is to choose test cases on the boundaries of the partitions plus cases close to the mid-point of the partition.
3. Structural testing:
-Use knowledge of the programs structure to design tests that exercise all parts of the program. Essentially, when testing a program, you should try to execute each statement at least onece.
-Also called whitebox where understanding the algorithm used in a component can help you identify further partitions and test cases.
4. Path testing:
-A strucutral testing strategy whose objective is to exercise every independent execution path through a component or program because if every independent path is executed, then all statements in the component must have been executed at least once.
-Furthermore, all conditional statements are tested for both true and false cases.
-The number of paths through a program is usually proportional to its size.
-The starting point for path testing is a program flow graph which is a skeletal model of all paths through the program. A flow graph consists of nodes representing decisions and edges showing flow of control. The objective of path testing is to ensure that each independent path through the program is executed at least once. An independent program path is one that traverses at least one new edge in the flow graph.
-Find the number of independent paths in a program by computing the cyclomatic complexity of the program flow graph. For programs without goto statements, the value of the cyclomatic complexity is one more than the number of conditions in the program (if has and or or then use number of simple statements)
-Or from CFG, edges-nodes+2 or regions+1
ESTIMATIONS:
1. Metric for testing:
>Based on two easily obtained parameters:
n1 = number of distinct operators in program
n2 = number of distinct operands in program
N1, N2 = total count of operators and operands in program
(paired operators such as begin..end, repeat..until are treated as single operator)
>Program length: N = N1 + N2
>Vocabulary: n = n1 + n2
>Estimated program length: H = n1lnn1 + n2lgn2
>Program volume: V = Nlgn
>Difficult: D = (n1/2)*(N2/n2)
>Effort: E = D*V
>Time required to program: T = E/18 seconds
>Number of delivered bugs: B = V/3000
2. Software productivity:
>Need productivity estimates to help define the project cost or schedule, to inform investment decisions or to access whether process or technology improvements are effective
1. LOC/pm:
>Widely used software productivity metric that compute LOC/pm by counting the total number of liens of source code that are delivered, then divide the count by total time in programmer-months required to complete the project, which includes the time required for all other activities like requirements, design, coding and documentation
>Problem:
-No simple relationship between program statements and lines on a listing
-High level language programmer might have LOC half than the high level programmer yet the development costs for the system developed in C are lower and is delivered earlier
2. Function-point count:
>Alternative is to use measure of functionality in code that is independent of implementation language
>Calculation steps:
-By measuring the program features:
1. external inputs or outputs
2. user interactions
3. external interfaces
4. file used by the system
-Multiplies the initial function-point estimate by complexity-weighting factor (3 for simple external inputs to 15 for complex internal files) which gives unadjusted function-point count
UFC = S(number of elements of given type * weight)
-Multiplies UFC by additional complexity factors that are related to the complexity of the system as a whole which takes into account the degree of distributed processing, amount of reuse, performance and so on.
-Result is the final function-point
>Problem:
-Subjective nature of complexities
-Biased towards data processing with dominated input and output operations
>AVC to implement a function point ranges from 200 to 300 LOC/FP in assembly, to 2 to 40 LOC/FP for a database programming such as SQL.
3. Object-point count:
>Easy to estimate from a specificaiton than function points so can be calculated fairly early point in the development process
>Number of object points in a program is a weighted estimate of
-Number of separate screens that are displayed
-Number of reports that are produced by the system
-Number of program modules that may be developed to supplement the database code
3. Cost estimation techniques:
>No simple way to make accurate estimate of the effort required to develop a software system, still organisations need to make software effor and cost estimates
a. Algorithmic cost modelling:
A model developed using historical cost information that relates some software metric (usually its size) to the project cost
b. Expert judgement:
Several experts on the proposed software development techniques and the application domain are consulted
c. Estimation by analogy:
The cost of a new project is estimated by analogy with the completed projects in same domain
d. Parkinson's law:
States that the cost is determined by available resources rather than by objective assesment
e. Pricing to win:
Software cost is estimated to be whatever the customer has available to spend on the project
ALGORITHMIC MODEL:
>Uses a mathematical formula to predict project costs based on estimates of the project size, number of software engineers, and other process and product factors.
>In general form, an algorithmic cost estimate for software cost can be expressed as:
Effort = A * Size^B * M
where,
-A is constant that depends on local organisational practices and the type of software that is developed
-Size is assesment of the code size or functionality estimate
-M is a multiplier made by combining process, product and development attributes, such as experience of the team
-B is a exponential compoent lies between 1 and 1.5 to reflect that costs do not normally increase with project size
COCOMO MODEL: (GRAPH)
>An empirical model based on project experience by colleting data from large number of software projects and analysed to discover formulae that were best fit to the observations, which link the size of the system and product, team facotrs to the effort to develop the system
>Advantages:
-Well documented, available in public domain and supported by commercial tools
-Widely used and evaluated in a range of organisations
-Went through many stages of refinements, latest being COCOMO II
>The first version COCOMO 81 assumes that the software would be developed accordint to waterfall process using standard imperative programming languages.
Simple: PM = 2.4 (KDSI)^ 1.05 * M
Well understood applications developed by simple teams
Moderate: 3.0, 1.12
More complex projects where team members may have limited experience of related systems
Embedded: 3.6, 1.20
Complex projects where the software is part of strongly complex of hardware, software and regulations
COCOMO II:
>Recognises different approaches to software development such as prototying, development by component composition and use of database programming.
>Sub-models:
1. Early design model
When requirements are available but design has not yet started
-The A is 2.94 and multiplier M depends on project and process characterisitcs such as product reliability and personal capabilities
2. Post-architectural model
Once system architecture has been designed, and more information about the system is available
-Same formula as early design but with 17 multipliers
3. Application composition model
Used when software is composed from existing parts
-Takes CASE tool use into account
-PM = (NAP*(1-%reuse))/PROD
4. Reuse model
Used to compute effor of integrating reusable components
-Takes into account black-box code that is resued without change and code that has to be adapted to intergate it with new code
-PM = (ASLOC*%AT)/ATPROD
4. Project duration and staffing:
>As well as effor estimation, managers must estimate the calendar time requried tto complete a project and when staff will be required
>Formula for all COCOMO levels:
TDEV = 3 * (PM)^[0.33+0.2*(B-1.01)], PM is effort computation
>The time required to complete the project is a function of the total effort required for the project. It does not depend on the number of software engineers working on the project. This confirms the notion that adding more people to a project that is behind schedule is unlikely to help that schedule to be regained
5. Reliability:
>A simple measure of reliability is mean-time-between-failure (MTBF),
MTBF = Mean-time-to-failure + Mean-time-to-repair
>Software availability is the probability that a program is operating according to requirements at a given point in time
Availability = MTFF/(MTTF+MTTR)*100%
QUALITY MANAGEMENT: >Software quality is an effective process applied in a manner that creates a useful product that provides measurable value for those who produce it and those who use it >Quality management concerned with ensuring that the required level of quality is achieved in software product which provides an independent check on software development process to ensure that they are consistent with organisational standards and goals >Importances: -A useful product delivers the content, functions, and features that end-users desires -Effective software process establishes the infrastructure that supports any effort at builiding a high qulaity software product -Organization gains added value as high qualtiy software requires less maintenance effort, fewer bug fixes and reduced customer support -User community gains added value as application provides a useful capability in a way that expedites some busines process -Great software product revenue, better profitability and improved availability
>Quality Dimensions:
1. Performance quality:
2. Feature quality:
3. Reliability:
4. Conformance:
5. Durability:
6. Serviceability:
7. Aesthetics:
8. Perception:
>Can be structured into three main activities:
1. Software quality assurance and standards:
-Process of establishing a framework of organisational procedures and standards that lead to high-quality software
-Reviews and audits software engineering activities to verify compliance with the defined software process while ensuring that deviations in software work and work products are documented and handled according to a documented procedure.
GOALS:
Reuquirements quality:
The correctness, completeness, and consistency of the requirements model will have a strong influence on the quality of all work products that follow
Design quality:
Every element of the design model should be assessed by the software team to ensure that it exhibits high quality and that the design itself conforms to requirements
Code quality:
Source code and related work products (e.g., other descriptive information) must conform to local coding standards and exhibit characteristics that will facilitate maintainability
Quality control effectiveness:
A software team should apply limited resources in a way that has the highest likelihood of achieving a high quality result.
-Why standards?
i. Based on knowledge about best or most appropriate practice for the company acquired after a great deal of trial and error so building it into a standard helps the company avoid repeating past mistakes
ii. Provide a framework for implementing quality assurance process. Given that standards encapsulate best practice, qualtiy assurance invovles ensuring that appropriate standards have been selected and used
iii. Assist in continuity where work carried out by one person is taken up and continued by another. Standards ensure that engineers within an organisational adopt the same practices.
>ISO 9000: (FIG)
-An international set of standards that can be used in development of a quality management system in all industries, ISO 9001, the most general of these standards, applies to organizations that design, develop and maintain products, including software
-Isnot specifically aimed at software development but sets out general principles that can be applied to software
1. Describes various aspects of quality process and lays out the organisational standards and procedures that a company should define
2. The process definition should include descriptions of documentation required to demostrate that the defined processes have been followed during product development
3. Does not constrain the processes used in any organisation in any way, allows flexibility across industrial sectors
-CONS:
-Small companies can be unbureacractic process and still be ISO 9000 compliant.
-No account of quality as experienced by users of the software
-Can be met by incomplete software testing, that does not include tests with different methods parameters
>Statistical SQA:
-Information about software errors and defects is collected and categorized
-An attempt is made to trace each error and defect to its underlying cause using the pareto principle (80 percent of the defects can be traced to 20 percent of all possible cause), isolate the 20 percent
-Six sigma is a statistical SQA in which 99.99966% of all the opportunities to produce some features of a component are statistically expected to be free of defects- 3.4 defects per million opportunities
2. Quality planning:
Selection of appropriate procedures and standards from this frameowrk, adpated for a specific software project
3. Quality control
>Definition and enactment of processes that ensure that software development team have followed project quality procedures and standards
>Involves monitoring the software development process to ensure that quality assurance procedures and standards are being followed, the deliverables from the software process are checked against the defined project standards in the quality control process.
>Quality reviews:
-Where the software, its documentation and the process used to produce that software are reviewed by a group of people
-Code, designs, specifications, test plans, standards etc. call all be reviewed.
-Review is responsible for checking that the project standards have been followed and that software and documents conform to these standards.
-Deviations from the standards are noted and the project manager is alerted to them
-Informal reviews:
1. A simple desk check of software engineering work product with a colleague
2. A casual meeting involving more than 2 people for purpose of reviewing a work product
-Formal reviews (FTR):
1. To uncover errors in function, logic or implementation for any representtation of the software
2. To verify that the software under review meets its requirements
3. To ensure that software has been presented according to predefiend standards
4. To achieve software that is developed in a uniform manner
5. To make projects more manageable
-Inspection:
SEI CMMI PROCESS IMPROVEMENT FRAMEWORK:
>The Software Engineering Institute (SEI), established to improve capabilities of the US software industy, came with the capability assesment framework called Software Capability Maturity Model
>In plethora of models that have been developed since, the SEI embarked on a new programme to develop an integrated capability model (CMMI) which supersedse the CMMs and integrates other engineering models
>The CMMI model is integrated to be a framework for process improvement that has broad applicability across a range of companies.
>It's staged version is compatible with CMM and allows an organisation's ssystem development and management processes to be accessed and assigned a maturity level from 1 to 5. Its continuous version allows for a finer-grain classification and rates
24 process areas on a scale from 1 to 6.
STAGED CMMI MODEL: (FIG)
>The staged CMMI model is comparable with the Software CMM in that it provides a means to assess an organisation’s process capability at one of five level
1. Initial
2. Managed
3. Defined
4. Quantitaely managed
5. Optimizing
>Each maturity level has an associated set of process areas and generic goals
>Process improvement is achieved by implementing goals and practices prescribed at each level, moving from the lower to the higher levels in the model
>Advantages:
-Compatible with CMMs
-Defines clear improvement pathway for organisations
>Disadvantages:
-May be appropriate to introduce goals and practices at higher-levels before lower-level practices so organisation could plan accordingly
CONTINOUS CMMI MODEL: (FIG)
>Continous maturity models do not classify an organisation according to discrete levels, rather they are finer-grained models that consider invidual or groups of practices and access the use of each practice.
>The continous CMMI rates each process area and assigns a capability assesment from level 1 to 6 at each process area
>Normally, organisations operate at different maturity levels for a different process area so result of continous CMMI is a capability profile showing each process area and its associated capability assesment.
>Organisations may develop actual and target capability profiles where the target profile reflects the capability levels for that process area that they would like to reach
>Advantages:
-Organisations can pick and chose processes to improve according to their own needs and requirements
-Allows more discretion and flexibility
SIMPLIFIED DESCRIPTION:
1. Process areas:
Identifies 24 process areas that are relevant to software process capability and improvement
2. Goals:
Abstract description of a desirable state that should be attained by an organisation. Has specific goals that are assocaited with each process area and that define the desirable state for that area
3. Practices:
Descriptions of ways to achieveing a goal. Up to seven specific and generic practices thaty may be associated with each goal within each process area
Example:
Process:
Requirement developmetn
Goal:
Requirements are analysed and validated, and a definition of the requirement functionaity is developed
Practice:
Analyse derived requirements to ensure that they are necessary and sufficient
Validate requirements to ensure that resulting product will perform as intended in user's environment
Identify incosistencies between requirements and project's plans
Other process areas in 'Managed':
2. Project planning: Establish and maintain plans that define project activities
3. Project monitoring and control: Provide undertanding into project's progress so that appropriate actions can be taken when project's performane deviates from plan
4. Supplier agreement management: Make acquisition of products and services from suppliers external to the project
5. Process and project quality assurance
6. Configuration management
CONFIGURATION MANAGEMENT >CM is development and use of procedures and standards for managing an evolving software system as system requirements always change during developmente and use, these have to be incorporated into new versions of the system. >Sometimes considered to be part of software quality management with same manager sharing quality management and configuration management responsibilities. >After QA team checks for acceptable quality, then it becomes a baseline system which are starting point for further development >Standards: CM should always be based on set of standards that define how items are identified, how changes are controlled and how new versions are managed Eg: IEEE standard for CM
>Configuration management planning:
1. The starting point for developing the plan should be a set of configuration management standards
2. Define what is to be managed (the configuration items) and a document naming scheme
3. Defines who takes reponsibility for the CM procedures and creation of baselines
4. Defines policies for change control and version management
5. Define CM records which must be maintained
6. Describes tools which should be used to assist the CM process and any limitaitons on their use
7. Defines prcess of tool use
8. Defines the CM database used to record configuration information
>Change management:
-Concerned with keeping track of the changes requested by users, developers, market forces, and ensuring that they are implemented in the most cost-effective way
1. The first stage in change management process is to complete a change request form (CRF) describing what change is required to the system. The CRF records the recommenddation regarding the change, estimated costs of change and dates when the change was requested, approved, implemented, and validated.
2. Once a change request has been submitted, it should be registered in the configuraiton database
3. Analysed to check that the change requested is necessary
4. For valid changes, the next stage of the process is change assessment and costng. The impact of the change on the rest of the system must be checked.
5. A change control board (CCB) should review and approve all change requests unless the changes simply invovle correcting minor errors
>Version and release management:
-The processes involved in version and release management are concerned with identifying and keeping track of the versions of a system.
-Version managers plan when new releases of a system should be created and distributed for deployment, ensures that versions management procedures and tools are properly applied, and plan and distribute new system releases
Versions:
>A system version is an isntance of a system that differes, in some way, from other instances in functionality, enhanced performance or software faults
>Some versions may be functionally equivalent but designed for different hardware or software configurations, which have only small differences called variants
>A system release is a version that is distributed to customers which should either include new functionality or should be intended for a different hardware platform given that versions could be created within an organisation for internal development or testing and may not be intended for release to customers
>Procedures for version identification should define an unambiguous way of identifying component versions
-Numbering: Simple naming scheme using linear or tree structure, V1, V1.1, V2.1 etc
-Attribute-based: Attributes like date, creator, language, can be associated with a version. Eg: AC3D (java, XP, jan 2003)
-Change-oriented: Integrates versions and the changes made to create these versions
Releases:
>System release managers are responsible for deciding when the system can be released to customers
>Considering that customers may not want a new reelase of the system, competition, marketing requirements
>May also include:
-An installation program or shell script to intall the system on target hardware
-Data files needed for the system
-Electronic and paper documentation
-Packaging and associated publicity
>System building:
-System building is the process of compiling and linking software components into a program that executes on a particular target configuration
-Different systems are now always supported by automated tools driven by 'build scripts'
-Considers:
do build instructions include required components
whether data file reference within components are correct
whether being built for right platform
if right version of compiler and other tools are specified,
why models are necessary?
[
many disciplines connection to principles,
what models do structure, tradeoffs, blueprint,
need many models for subtelties eg: for electrical
no silver bullet yet discipline
OOD resilent to change with economy of expression and greater confidence through separation of concern
to cope with inherent complexity
]
practices/elements of OO model: (practise, promotes, achieved, additional, examples)
1.encapsulation:
-practice of hiding implementation and exposing public interface for other objects to interact
-better organization, reduce complexity, improve security, modular code design
-achieved through the use of classes and access modifiers
-abstraction and encapsulation are complementary concepts: encapsulation focuses on observable bevhaior while encapuslation gives rise to this behvaior
-EXAMPLE; a class representing a car in racing game, maintains public interface of accelerate(), brake(), turn(), collide() which other objects in game can use to interact with the car but the implementation details of the car would be hidden from the outside world
2.inheritance:
-practice of creating new classes that are basesd on existing classes, allowing them to inherit properties and methods from parent class
-code reuse, reduces duplication, hierarchial structure
-achieved through hierarchy of superclass or base class, and child class aka derived class
-implies a generalization/specialization hierarchy: is a hierarchy
-EXAMPLE; a class hierarchy for different type of animals; parent class might be a generic Animal class with subclasses for more specific types of animals such as Mammal, Bird, inherit from Animal such as ability to eat, sleep and move, while a Bird subclass might add its own methods for flying and laying eggs while still inherting the basic animal behavior from the parent class
3.polymorphism:
-ability of objects to take on multiple forms or behaviors depending on the context in which they are used
-flexibility, extensibility, modularity
-achieved through use of method overriding and overloading virtual functions
-allows objects of different classes to be treated as if they were of the same class, based on their shared behavior.
-EXAMPLE; a program for calculations, program might have different classes for types of calculations such as Addition, Subtraction and multiplicaiton, each class would have a common claculate() method but would implement it different depending on the specific type of class
differences between OO and other systems:
1. process models:
-procedular system often developed using the waterfall or spiral process models linear and involve completing such stage of development before moving on to the next stage
-are often developed using the Agile or Unified Process Models are iterative and involve developing small piece of functionality in short sprints
2. system design:
-"top-down" programming, where the program is divided into smaller modules, and each module is a procedures and functions that manupulate data
-OOP is based on the concept of "bottom-up" programming, where the program is designed around the objects and their interactions.
3. encapsulation
4. inheritance
5. polymorphism
types of models: (represents, useful, examples)
-each serving a specific purpose and providing valuable insights into the system being designed
1. Conceptual model:
-represents high level domain specific concepts and relationships in the problem domain expressed in business terminology
-useful for capturing essence of the problem being solved and for communicating with non-technical stakeholdres
-tecnoagnostic
-EXAMPLE: a online book store include high level class diagram representing concepts and relationshis in hotel domain such as hotels, guests, rooms, pricing, reviews
2. Logical model:
-represents the system's functonal requirements and logical design, including the structure of data, behavior and control flow
-useful for understanding's the system's behavior and for communicating with developers and testers
-technology-specific
-EXAMPLE: Include use case, activity diagrams, class, .., a logical model could include use cases for searching for available books, reviewing a book, managing customer informatin
3. Physical model:
-represent's the system's physical architecture, including hardware, networks, and deployment topology
-useful for understanding the system's performance, scalability and reliability requirements
-EXAMPLE: server infrastructure, databases and load balancers that are required to support the system
4. Strucural model:
-represents system's static structure, inclduing the classes, objects, interfaces and their relationships
-useful for understanding the system's OOD and for communicating with develoopers
-EXAMPLE: could include the classes for books, authors, customers and orders, and their relationships
5. Behavioral model:
-Represents the system's dynamic behavior including the sequence of events and interactions between objects and components
-useful for understanding the system's behavior, identifying use cases and scenarios, and for communicating with devlopers and testsers
-EXAMPLE: could include a sequence diagram for ordering a book, showing steps involved in searching available books, and paying for the book
unified process model:
-software development methodology that provides a comprehensive, iterative and incremental framework for developing high-quality software systems
FEATURES:
-Based on principles of OOD and it utilzies the UML as a visual language for expressing software desgins
-Development is organized into a series of short, fixed-length i.e. iterations are timeboxed (for eg, four week) mini-projects called iterations; the outcome of each is a tested, integrated, and executable system
-Each iteration takes new requirements and incrementally extends the system, an iteration may occasionally revisit existing softwae and improve it;
1. Inception:
-Identifying the business problem that the software system will solve and determining whether it is feasible to develop the system
-project scope is defined, the initial requirements are gatherered and stakeholdersl are defined
-deliverables include project feasibility report
2. Elaboratoion:
-requirements gathered in the inception phase are refined, and the architecture of the system is designed,
-development team also establishes a development plan for the project which includes porject scheudler, budget and resources
-deliverables include software architecture
3. Construction:
-where actual development of the software system takes place, development team writes the code, tests it, and integrates it into the system
-is iterative, and each iteration typically lasts between two to six weeks
-deliverables include test report
4. Transition:
-software system is deployed to the end-users with focus on ensuring that the system words as intended, and any defects or issues are resolevd
-includes maintainence of the sytem after deployment
-is the deployment plan
-UP is not a rigid, one-size-fits-all process but rather a framework that can be adapted and tailored to suit the specific needs of a given project
OOA, OOD and OOP:
-OOA, ODD and OOP are interleated concepts in the field of software engineering
1. OOA
-OOA refers to the process of analyzing the requirements of a system and modeling them using object-oriented concept
-involves identifying the objects, classes, and relationships that exist in the system and determining their behavior and attributes
-output is a conceptual model of the system that can be used to design and implement the system
2. OOD:
-process of taking the conceptual model produced by OOA and transforming it into detailed esign that can be implemented using a specific programming language
-involve defining classes, methods and interfaces that will be used in the system, as well as identifying the relationships and interactions between them
-output are design models that serve as blueprint for implementation and writing codes
3. OOP:
-process of actually implementing the design in a programming language that supports object oriented concepts
-involves writing code that defins the classes, methods and interfaces identifeid during OOD and OOA
These three processes are interrelated in that they build upon each other. OOA provides the high-level conceptual model of the system, which is then refined and detailed during OOD. The OOD output serves as a blueprint for the actual implementation of the system using OOP.
UML diagrams and all those shits:
-Visual modeling language used in software engineering to represent and document sofware systems
-Consists of several building blocks:
1. Structural elements:
-Represent the static structure of a system and include classes, objects, interfaces, components, and packages
-eg: a class diagram can be used to represent the classes in a system, their attributes, methods, and relationships
2. Behaviroal elements:
-Represent the dynamic behavior of a system and include use cases, interactions, state machines and activities
-eg: a use case ddiagram can be used to represent the different ways in which a system can be used by its actors
3. Grouping elements:
-Represent different ways of organizing and grouping UML elements such as subsystems, partiitions, and packages
-eg: a package diagram can be used to group related UML elements into logical package
4. Annotaional elements:
-Include notes, comments, and stereotypes that can be used to promote additoinal information or to clarify the meaning of UML elements
5. Rleationships:
-Represent the connections and associations between different UML elements, such as inherticatnce, aggreagtion and association
Requirement elicitation: -Requirements are capabilities and conditions to which the system -and more broadly, the project must conform -The UP promotes a set of best practices, one of which is manage requirements, this does not refer to the waterfall attitude of attempting to fully define and stabilize the requirements in the first phase of the project, rather in the context of inevitably changing the unclear stakeholder’s wishes in a systematic approach to finding, documenting, organizing, and tracking the changing requirements
1. Establish the visiion: Involves identifying the goals and objectives of the system, and determining the scope of the project
2. Identify stakeholders: Next step is to identifying the stakeholders who will be impacted by the system, includes end-users, custsomers, managers, and developers
3. Gather requirements: Next is to gather requirements fromt hem through various techniques such as interviews, surveys and observations
4. Analyze requirements: Then analyzed to identify any inconsistnecies, conflicts, or missing information, clarifying the requirements and veryfing their accuracy
5. Prioritize requirements: Must be prioritized based on their importance and impact on the system
6. Specify rewuirements; Must be specificed in a clear and concise manner using appropriate notations, such as UML diagrams, to dcoument the reosurecs
7. Validate rquiremtns; FInally must be validated to ensure that hey meed the stakeholder's neeeds and are consistent with the system's goals
Different types of requirements used to describe an object-oriented system include:
Functional requirements: These describe what the system should do, such as providing specific features and functions.
Non-functional requirements: These describe the qualities of the system, such as performance, reliability, and security.
User requirements: These describe the needs and expectations of the system's users.
Business requirements: These describe the goals and objectives of the system from a business perspective.
System requirements: These describe the technical aspects of the system, such as the hardware and software requirements.
Domain requirements: These describe the characteristics of the problem domain, such as industry-specific rules and regulations.
=====================================================================================================
Why software is inherently complex? 1) Complexity of the problem domain: 2) Difficulty of managing the development process: 3) The flexibility possible through software 4) The problems of characterizing the behaviour of discrete systems
Five attributes of a complex system: 1) Hierarchic structure: 2) Relative primitives: 3) Common patterns: 4) Separation of concerns: 5) Stable intermediate forms:
The importance of model building: -Building of models has a broad acceptance among all engineering discipline, largely because model building appeals to the principles of decomposition, abstraction and hierarchy -The products of design are models that enable us to reason about our structures, make trade-offs when requirements conflict, and in general, provide a blueprint for implementation -Models give us the opportunity to fail under controlled conditions, we evaluate model in both expected and unusual situations, and then we alter them when they fail to behave as we expect or desire -In order to express all the subtleties of a complex system, we must use more than one kind of model, each model within a design describes a specific aspect of the system under construction -For example, when designing a personal computer, an electrical engineer must take into consideration the component-level view of the system as well as the physical layout of the circuit boards -There is no silver bullet that can unfailingly lead the software engineering down the path from requirements to the implementation of a complex software system, still sound design methods do bring some much-needed discipline to the devlopment process -Software engineering community has evolved dozens of different design methodologies, which can loosely classify into three categories:
>Notation: The language for expressing each model
>Process: The activities leading to the orderly construction of the system's models
>Tools: The artifacts that eliminate the tedium of model building and enforce rules about the models themselves, so that errors and inconsistencies can be exposed
-By appling OOD, we create software that is resilient to change and written with economy of expression, achieve a greater level of confidence in the correctness of our software through an intelligent separation of its state space (concern)
-The reason for widespread appeal of object model is simply that an object orientation helps us to cope with the complexity inherent in many different kinds of systems
Types of models: 1) Conceptual model: -The conceptual model captures the system in terms of the domain entities that exist (or will exist) and their association with other such entities of your system, performed using the terminology of your business domain and should be technology-agnostic
2) Logical model
-The logical view of a system takes the concepts created in the conceptual model and establishes the existence and meaning of the key abstractions and mechanisms that will determine the system’s architecture and overall design.
3) Physical model
-The physical model of a system describes the concrete software and hardware composition of the system’s implementation, is technology-specific.
I) Structure diagrams:
-Show static structure of elements in the system
-May depic things such as the architectural organization of the system, the physical elements of the system, its runtime configuration, and domain-specific elements of business, among others
-Often used in conjuction with behavior models to depict a particular aspect of the system
-Each class may have an associated state machine diagram that indicates the event-driven behavior of the class's instances
II) Behavior diagrams:
-As events happen dynamically in all software-intensive systems, objects are created and destroyed, objects send messages to one another in an orderly fashion, and external events trigger operations on certain objectss
Elements of object model: -Object oriented programming system is based on its own conceptual framework which is the object model of which the four major elements are: 1) Abstraction 2) Encapsulation 3) Modularity 4) Hierarchy -A model without any one of these elements is not object-oriented -Three minor elements of object mdel are: 1) Typing 2) Concurrency 3) Persistence
ABSTRACTION: -One of the fundamental ways that we as humans cope with complexity -A simplified description, or specificaiton, of a system that emphasizes some of the system’s details or properties while suppressing others -An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer -Can characterize the bevavior of an object by considering the services that it provides to other objects, as well as the operations that it may perform on other objects -Each operation that contriutes to this contract has a unique signature comprising all of its formal arugments and return type -Central to the idea of an abstraction is the concept of invariance, which is some Boolean condition whose truth must be preserved, for each operations associated with an object, we may define precautions (invariants assumed by the operation) as well as postconditions (invariants satisfied by the operation) -An exception is an indication that some invariant has not been or cannot be satisfied, certain languages permit objects to throw exceptions so as to abandon processing and alert some other object to the problem, which is turn may catch the exception and handle the problem -EXAMPLES: >On a farm, plants are grown maintaining proper greenhouse, one of they key abstractions is that of a heater, viewed from the outside, a heater is simply an object that increases the temperature of its content
>Abstraction: Heater
>Important Characteristics:
-location
-status
>Responsibilities:
-turn on
-turn off
-provide status
ENCAPSULATION: -Abstraction and encapsulation are complementary concepts; abstraction focuses on the observable behavior of an object, whereas encapsulation focuses on the implementation that gives rise to this behavior -Achieved through information hiding, which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics; typically, the structureof an object is hidden, as well as the implementation of its methods -The process of compartmentalizing the elements of an abstraction that can constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation -EXAMPLES >Turning to the inside view of the heater, we have an entirely different perspective, one reasonable implementation for the heater class might be to use an electromechanical relay that controls the power going to each physical heater, for example, to turn on a heater, we might transmit a special command string, followed by a number identifying the specific heater, followed by another number used to signal turning the heater on >For whatever reasons if engineering choose to use memory mapped IO instead of serial lines, need not to change the interface of the heater, yet the implementation would be very different, the client would not see any change at all as the client sees only the heater interface
MODULARITY: -Partioning a program into individual components can reduce its complexity to some degree as well as creates a number of well-defined, documented boundaries within the program -In many languages, the module is a separate language construct and therefore warrants a separate set of design decisions, wherein classes and objects form the logical structure of a system; we place these abstractions in modules to produce the system’s physical architecture -The connections between modules are the assumptions which the modules make about each other, most languages that support the module as a separate concept also distinguish between the interface of a module and its implementation, thus modularity and encapsulation go hand in hand
HIERARCHY: -A set of abstractions often forms a hierarchy, and by identifying these hierarchies in our design, we greatly simplify our understanding of the problem: -Two most important hierachies in a complex system are its is-a hierarchy and part-of hierarchy EXAMPLES: >Inheritance is the most important is-a hierarchy, which defines a relationship among classes, wherein one class shares the structure or behavior defined in one or more classes >Inheritance thus implies a generalization/specialization hierarchy, wherein a subclass specializes the more general structure or behavior of its superclasses, indeed, this is the litmus test for inheritance: if B is not a kind of A, then B should not inherit from A. >The “part of” hierarchies describe aggregation relationships, can contend that a garden consists of a collection of plants together with a growing plan >Our abstraction of a garden permits different plants to be raised in a garden over time, but replacing a plant does not change the identity of the garden as a whole, nor does removing a garden necessarily destroy all of its plants (they are likely just transplanted) >In contrast, we have decided that a GrowingPlan object is instrinscially associated with a garden object and does not exist independently, therefore, when we create an instance of Garden, we also create an instance of GrowingPlan; when we destroy the Garden object, we in turn destroy the GrowingPlan instance
Unified Process (UP): -Combines commonly accepted best practices, such as iterative lifecycle and risk-driven development, into a cohesive and well-documented description -Small steps, rapid feedback, and adaptation are central ideas in iterative development -Features: -Draws best features from classical and implement with best principle of agiles -Development is organized into a series of short, fixed-length i.e. iterations are timeboxed (for eg, four week) mini-projects called iterations; the outcome of each is a tested, integrated, and executable system -Each iteration takes new requirements and incrementally extends the system, an iteration may occasionally revisit existing softwae and improve it; -Managed complexity; the team is not overwhelmed by analysis paralysis or very long and complex steps -Major phases: >Planning by collaborating with customers to prepare basic architectures >Elaboration refines and expands the use case developed in inception >Construction of necessary features >Transition for later consturctiona and early deployement >Production is for deployment and monitoring to provide support -Diagram illustrating how the relative emphasis of different disciplines change over the course of the project
Object-oriented analysis: -Analysis emphasizes an investigation of the problem and requirements, rather than a solution -A method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain -The products of OOA serve as the models from which we may start an OOD; the products of OOD can then be used as blueprints for completely implementing a system using OOP methods
Object-oriented design: -Design emphasizes a conceptual solution that fulfills the requirements, rather than its implementation -A method of design ecompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the sytem under design
Object-oriented programming: -A method of implementation in which programs are organized as cooperative collection of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships -Programming without inheritance is distinctly not object-oriented; that would merely be programming with abstract data types
The role of decomposition: -When designing a complex software system, it is essential to decompose it into smaller and smaller parts, each of which we may then redefine independently -In contrast to algortihmic decomposition, wherein each module in the system denotes a major step in some overall process, object-oriented decomposition stands for -Decomposed the system according to the key abstractions in the problem domain -We view the world as a set of autonomous agents that collaborate to perform some high-level behaviour -Each object in our solution embodies its own unique behavior, and each one models some object in the real world, from this perspective, an object is simply a tangible entity that exhibits some well-defined behavior -Cannot construct a complex system in both ways simultaneously, for they are completely orthogonal views, must start decomposing a system either by algorithms or by objects and then use the resulting structure as the framework for expressing the other persepective -Advantages: -reduces the risk of building complex software systems because they are designed to evolve incrementally from smaller systems in which we already have confidence -yields smaller systems though the reuse of common mechanisms, thus providing an important economy of expression -addresses the inherent complexity of software by helping us make intelligent decisions regarding the separation of concerns in a large state space -more resilient to change and thus better able to evolve over time beause their design is based on stable intermediate forms
ANALYSIS PART: |
USE CASES: -Find the user goals, define a use case for each (use goal and not system’s, such as securtiy is not a user goal) -Log in is not a user goal it is a subfunction goal, is not a elementary business process -But can be put if subfunction is repeated in or is a precondition for multipe user goal level use cases, which is true for login
-FOMRAT: (tabular form ma lekhey best)
Use case name:
Actor(s):
Use case purpose:
This use case provides the ability to maintain the fill levels of the contents of the storage tanks. This use case allows the acto to maintain specific sets of water and nutrient tanks
Optimistic flow:
A: Actor examines the levels of the storage tanks' contents
B: Actor determines the tanks need to be refilled
...
Pragmatic flows:
Condition 1: There is insufficient material to fill tanks to the levels specified by the actor
D1: Alert actor regarding insufficient material available to meet tank setting
D2: Promt actor to choose to end maintainance or reset fill levels
D3: If reset chosen, perform step D
D4: If end maintenance chosen, perform step H
...
-Use case diagram:
- system ko name ra boundary bhaihalyo internal functions ra outside world lai chuttaune
- actors chai must interact with the system under development
- system ko dallo bhitra use cases haru
- includes ra extends ko direction haldini, main use case -> included use case; main use case <- extendd use case
- generalization xa bhane haldini (actors ma chai hunxa nai, use case ma haldiye ni bhayo)
- each actor chai use case ma take part garni ho hai, mero tero use case bhanni hudaina
- doubt here is: atm machine ko system banauda atm machine nai actor ma rakheko hunxa, tyo atm machine chai tyo hardware lai bhaneko huna sakxa not the system lai (jun lai hamle develop garna lako software hunxa)
-An include relationship is a one in which one use case (the base) includes or uses or may contain the functionality of another use case (the inclusion)
-System sequence diagram: (more details needed, coming later)
-A system sequence diagram is a picture that shows, for a particular scenario of a use case, the events that extenral actors generate, their order, and inter-system events
-All systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems
-A SSD should be done for the main sucess scenario of the use case, and frequent or complex alternative scenarios
-euta actor hunxa, ani euta system hunxa, duitai ko lifeline dotted form ma matra hunxa
-loop garauna milxa majale same uml format ma
-tei syncrhonous and asynchornous messages haru bhaihaley, synch means that there is a communication with replies and shits, async means open ended communication
-communications lai makeNewSale() jasari lekhni, or enterItem(itemID, quantity)
-(ARU ACTORS HARU NI EXTERNAL SYSTEM HARU NI THAPNA MILXA)
-Activity diagrams (here proably or in design?)
-IN ANY UML TO WRITE NOTES MAKE A BUBBLE THEN DOTS AND MAKE A NOTE SYMBOL AND WRITE ON IT
Conceptual model:
-
[represents, what to include?, examples, and difference with DCD]
1. Conceptual class:
-Informally, a conceptual class is an idea, thing, object, agents that collaborate to perform some high-level behavior
-Includes noteworthy abstractions, domain vocabulary, and information content of the domain
-A visualization of things in the real-world domain of interest, not of software components such as Java or C++ class, or software objects with responsibilities, therefore following elements are not suitable in a domain model:
1. Software artifacts,
2. Responsibiliies or methods
-Incremental and iterative nature of classification directly impacts the construction of class and object hierarchies in the design of a complex software system
> Use of analysis pattern
-Existing partial domain models created by experts
> Identify noun phrases:
-Another useful technique is linguistic analysis because of its simplicity; identify nouns and noun phrases in textual descriptions of a domain
-Care must be applied as a mechanical noun-to-class mapping isn't possible, and words in natural language are ambiguous
-Example from use case:
1. Customer arrives at a POS checkout with goods and/or services to purchase
....
Extensions:
7a. Cashier enters the cash amount tendered
...
> Use a conceptual class category list
-Start by creation of a domain model by making a list of candidate conceptual classes
1. physical or tangible objects: Register, Airplane
2. specifications, designs, or description of things: FlighSpecs, ProductSpecs
3. places: Store, Airport
4. transactions: Sale, Payment, Reservation
5. roles of people: Cashier, Pilot
6. container of other things: Store, Bin
7. things in a container: Item, Passenger
8. other computer or electro-mechanical systems external to the system: AirTrafficControl
9. abstract noun concepts: Hunger, Acrophobia
10. organizations: ObjectAirline, SalesDepartment
11. events: Sale, Payment, Meeting, Flight
12. process: SellingAProduct, BookingASeat
13. rules and policies: RefundPolicy, CancellatioinPolicy
14. catalogs: ProductCatalog
15. records of finance, work, contracts, legal matters: ReceiptLedger, MaintenanceLog
16. financial instruments and services: LineOfCredit, Stock
17. manuals, documents, books, papers: RepairManual
2. Attributes:
-An attribute is a logical data value of an object that represent the properties or characteristics that define each object
-To include in a domain model, those for which the requirements (for example, use cases) suggest or imply a need to remember information
-Common attribute data types include primitive data ttypes: boolean, date, number, string, time, address, color, geometries, phone numbers, product code, zip etc, for ex: a receipt normally includes a date and time, should not be a complex domain concept such as a Sale or Airport
-The restriction that attributes in the domain model be only of simple data types does not imply that C++ or Java attributes (data members, instance fields) must only be of simple, primitive data types. The domain model focuses on pure conceptual statements about a problem domain, not software components
-Associations:
-An association is a relationship between types (or more specifically, instances of those types) that indicates some meaningful and interesting connection
-More formally, UML are defined as the semantic relationship between two or more classifiers that involve connections among their instances
-To include the following associations in a domain model
1. Associations for which knowledge of the relationship needs to be preserved for some duration ('need-to-know' asociations)
2. Associaitons derived from the Common Associations List
-Do we need to remember what SalenLineItem instances are associated with a Sale instance?, yes otherwise it would not be possible to reconstruct a sale, print a receipt, or calucate a sale total
-By constrast, do we need to have memory of a relationship between a current Sale and a Manager?, no, the requirements do not suggest that any such relationship is needed
-Categories:
1. A is a physical part of B: Wing - Airplane
2. A is a logical part of B: FlightLeg - FlightRoute
3. A is physically contained in B: Passenger - Airplane
4. A is a description for B: FlightDescription - Flight
5. A is a line item of a trasaction or report B: Maintenance Job - Maintenance Log
6. A is recorded/known/captured in B: Sale - Register
7. A is member of B: Cashier - Store, Pilot - Airline
8. A is an organizational submit of B: Department - Store
9. A uses or manges B: Pilot - Airplane
10. A communicates with B: Customer - Cashier
11. A is related to a transaction B: Customer - Payment
12. A is a transaction realated to another transaction B: Payment - Sale, Reservation - Cancellation
13. A is next to B: City - City
14. A is owned by B: Plane - Airline
15. A is an event related to B: Departure - Flight
-1, 2, 6 are high-priorty associations
-Multiplicity defines how many instances of class A can be associated with one instance of class B
-(euta lai 1 rakhda arko kati sanga associate hunxa ta bhanni patta lagauna opposite wala ma herni)
-Multiplicity value is dependent on our interest as a modeler and software, because it communicates a domain constraint that will be reflected in software
-Association names should start with a capital letter, since an association represents a classifier of links between instances; in the UML, classifiers should start with a capital letter
-Two types may have multiple associations between them; the flying-to and flying-from associations are distinctly different relationships
-During domain modeling, an association is not a statement about data flows, instance variables, or object connections in a software solution; it is a statement that a relationship is meaningful in a purely conceptual sense -in the real world
-When creating a domain model, we may define associations that are not necessary during implementation, conversely, we may discover associations that need to be implemented but were missed during domain modeling
-Aggregation and compositon:
-Aggregation is a kind of association used to model whole-part relationships between things. The whole is called the composite.
-Aggregation is a property of an association role, the association name is often excluded in aggregation relationships since it is typically thought of as Has-part.
-Composite aggregation, or composition, means that the part is a member of only one composite object, and that there is an existence and disposition dependency of the part on the composite. For example, a hand is in a composition relationship to a finger
-If the multiplicity at the composite end is exactly one, the part may not exist separate from some composite
-Shared aggregation means that the multiplicity at the composite end may be more than one, and is signified with a hollow diamond.
-It implies that the part may be simultaneously in many composite instances.
-Shared aggregation seldom (if ever) exists in physical aggregates, but rather in nonphysical concepts
(bhannale dark dallo bhayo bhane ki euta ko part hunxa ki 0 ota ko part hunxa, natra multiple ko part huna payo)
>Importances:
-operations such as copy and delte applied to whole often propagate to the parts
-assists in identificaation nof creater using the grasp creator pattern
-Generalizations: (later iterations)
-Activity of identifying commonality among concepts and defining superclass and subclass relationships, a way to construct taxonomic classifications among concepts which are then illustrated in class hierarchies
-Identifying a superclass and subclasses is of value in a domain model because their presence allows us to understand concepts in more general, refined and abstract term, leads to economy of expression, improved comprehension and a reduction in repeated information
-Related in terms of set membership, all the members of a conceptual subclass set are members of their superclass set
-100% of the conceptual superclass's definiton should be applicable to the sub-class, subclas must conform to 100% of the superclass's attributes and association
-Cash payment, credit payment and check payment -> payment
-When to partion in subclasses?
>The subclass has additional attributes of interest
>The subclass concept represents an animate thing (for example, animal, robot) that behaves differently than the superclass or other subclasses, in ways that are of interest
: |
Adding details with operation contracts: (SSD ma bhako messsage haru lai state change ko form ma dekhauni) -Contracts describe detailed system behavior in terms of state changes to objects in the Domain model -May be defined for system operations that the system as a black box offers in its public interface to handle incoming system events -There are situations where the details and complexity of required state changes are awkward to capture in use cases -In an airline reservation system and system operation addNewReservation, the complexity if very high regarding all the domain objects that must be changed, created and associated -Example: Contract CO2: enterItem (this is header) (box starts here) Operation: Cross enterItem(itemID: itemID, quantity: integer) References: User Cases: Process Sale Preconditions: There is a sale underway Posconditions: -A SalesLineItem instance sli was created (instance creation) -sli was associated with the current Sale (association formed) -sli.quantity became quantity (attribute modification) -sli was associated with a ProductSpecification, based on itemID match (association formed)
-The postconditions describe changes in the state of objects in the Domain Model, whose state include instances created, associations formed or broken, and attributes changed
Requirements to design: -In iterative development, a transition from primarily a requirements focus to primarily a design and implementation focus will occur in each iteration -Natural and healthy to discover and change some requirements during the design and implementation work of the early iterations -These discoveries will both clarify the purpose of the design work of this iteration and refine the requirements understanding the future iterations -During OOD, a logical solution based on OOP is developed, heart of which is the creation of interaction diagrams, which illustrate how objects collaborate to fulfill the requirements -The creation of interaction diagrams requires the application of principles for assigning responsibilities and the use of design principles and patterns -In practice, the creation of interaction and class diagrams happens in parallel and synergistically
COLLABORATION:
-a link is a connection path between two objects; it indicates some form of navigation and visibility between the objects is possible, more formally, a link is an instance of an association
-aba link b ata chai message flow hunxa, numering garera order chuttane ani same link use garera multiple messages haru ohordohor hunxa
-message chai tei makePayment(cash) jasari garauni ho small arrow le direction janayera
-euta self message pani hunxa sakxa, message to self or this, jun chai wire le self associate garera message dekhauni
-euta message le chai instance create garna sakxa (aile samma ta preexisting objects haru sanga comm thiyo) aba special create(parameters) use garera naya instance create garna sakinxa, tyo object lai :Name {new} jasari lekhinxa
-message number ma first message chai numebered hudaina (jasle collab lai suru garayo)
-Order and nesting of subsequent messages is done by prepending the incoming message number to the outgoing message number, eg: euta obj le euta message say 2: msg() receive garera duita subsequent message return garyo bhane teslai 2.1 msg1() and 2.2 msg2() garera denote garinxa
-conditional message lai 1 [color = red]: msg() garera denote garinxa
-iteration or looping in message as 1*[i:=1...N]: num:=nextInt()
-iterate over a collection: 1 *: st:=getSubTotal() ra multiobject lai denote garna duita box banauni
-message lai static method jasari class ma pathauna milxa
(now mathi kura garethim ni patterns ko barema)
GRASP (General responsibility assignment software principles) -Expereince OO developers build up a repertoire of both general principles and idiomatic solutions that guide them in the creation of software, these prinicples if codified in a structured format describing the problem and solution, and given a name, may be called patterns -Responsiilibty is a contract or obligation of a classifier -Example: Pattern Name: Information Expert Solution: Assign a responsibility to the class that has the information needed to fulfill it Problem It Solves: What is a basic principle by which to assign responsibiiltes to objets? -GRASP are fundamental principles of object design and responsibility assignment, expressed as patterns -Aid to help one understand essential object design, and apply design reasoning in a methodical, rational, explainable way -Responsibilites are related to the obligations of an object in terms of its behavior, formally is a contract or obligation of a classifier -Two types: 1. doing: -doing something itself, such as creating an object or doing a calculation -initiating action in other objects -controlling and coordinating activites in other objects
2. knowing
-knowing about private encapuslated data
-knowing about related objects
-knowing about things it can derive or calculate
-Responsibilites are assigned to classes of objects during design, for example, I may declear that 'a Sale is responsible for creating SalesLineIems' (a doing), or 'a Sale is responsible for knowin its tatal' (a knowing)
-A responsibility is not the same thing as a method, but methods are implemented to fulfill responsibilities, implemented using methods that either act alone or collaborate with other methods and objects
Patterns: 1. Information Expert
Solution: Assign a responsibility to the information expert - the class that has the information necessary to fulfill the responsibility
Problem: What is a general principle of assigning responsibilites to objects?
Example: Who should be responsible for knowing the grand total of a sale?
By, Information Expert, we should look for the class of objects that has the information eeded to determine the total
(If there are relevant classes in Design Model, look there first, if there is no or minimal Design Model, look in the Domain Model)
-balla diagram banauna thalexa bhani ta design model ta emtpy hunxa, teti bela domain model ma herni ho, ani ali ali banisakyo ra hamlai chaiyeko class haru aaisakyo bhane balla design model ma herni ho
Perhaps, the real-world Sale is one, then we add a software class to the Design Model similarly called Sale, and give it the responsibility of knowing its total, expressed with the method named getTotal. It is necessary to know all the SalesLineItem instances of a sale and the sum of their subtotals, What information is needed to determine the line item subtotal? SalesLineltem.quantity and ProductSpecification.price are needed. The SalesLineltem knows its quantity and its associated ProductSpecification; therefore, by Expert, SalesLineltem should determine the subtotal; it is the information expert
2. Creator
Pattern Name:
Solution: Assign class B the responsibility to create an instance of class A if one or more of the following is true:
1. B aggregates A objects
2. B contains A objects
3. B records insances of A objects
4. B closely uses A objects
5. B has the initializing data that will be passed to A when it is created (thus B is an Expert with respect to creating A).
(If more than one option applies, prefer a class B which aggregates or contains class A)
Problem: Who should be responsible for creating a new instance of some class?
Example: In POS, who should be responsible for creating a SalesLineItem instance? By Creator, we look for a class that aggregates, contains, and so on, SalesLineItem instances, since a Sale contains many SalesLineItem objects, the Creator pattern suggests that Sale is a good candidate to have the responsibility of creating SalesLineItem instances
3. Low Coupling
Pattern Name: Low coupling
Solution: Assign a responsibility so that coupling remains low
Problem: How to support low dependency, low change impact, and increased reuse?
>Couping is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements
>An element with low or weak coupling is not dependent on too many other elements; a class with high coupling relies on many other classe such may be undesirable, some suffer from following problems:
-Changes in related classes force local changes
-Harder to understand in isolation
-Harder to reuse because its use require the additional presence of the classes on which it is dependent
-Example:
Register class creates a payment and adds it to Sale class, but better is for Register to makePayment() to Sale while Sale create Payment instance
4. High Cohesion
Pattern Name:
Solution: Assign a responsiblity so that cohesion remains high
Problem: How to keep complexity manageable?
Cohesion is a measure of how strongly related and focused the responsibilites of an element are, an element with highly related responsibilites, and which does not do a tremendous amount of work, has high conhesion, a class with low cohesion does many unrelated things, or does too much work so they suffer from:
-Hard to comprehend
-Hard to reuse
-Hard to maintain
-Delicate
-Example: Same example as coupling: reigster le duita kaam garni bhani, If we continue to make Register class responsible for doing some or most of the work related to more and more sysm operation, it gets burdend with tasks, so arko tarika use garni
COHESION AND COUPLING; YIN AND YANG:
-Bad cohesion usually begets bad coupling, and vice versa
5. Controller ...
Solution: Assign the responsibiilty for receiving or handling a system event message to class representing one of the following choices
-Represents the overall system, device, or subsystem
-Represents a use case scenario within the system event occurs, often named <Usecase>Handler
Problem: Who should be responsible for handling an input system event?
>Input system event is an event generated by an external actor, associated with sytem operations -operaions of the system in response to system events, just as messages and methods are related
>A controller is a non-user interface object responsible for receiving or handling a system event
>(uta user le kei garyo, tyo event/message ta UI ko class ma janxa hola ani, tespaxi Domain Model ma aayesi koslai diney ta?)
6. Polymorphism
Solution:
CRC Cards: -Not formally part of UML, but help assign responsibilities and indicate collaboration with other objects are CRC cards -Are index cards, one for each class, upon which the responsibilites of the class are briefly written, and a list of collaborator objects to fulfill those responsibilites -Are one approach to recording the result of responsibility assignemnt and collaborations, can be enhanced with the use of interaction and calss diagrams
(aba chai design model banauni ho sayad not just class diagram hai both seequence diagrams also, mathi ko ta syntax matra ho)
Use-Case Realizations: -A use-case realization describes how a particular use case is realized within the design model
>---> May be possible to design use-case realizations directly from the usecase text, in addition, for some system operations, contracts may have been written that add greater detail or specificity
>---> Some of the software objects are inspired from the Domain Model, such as a Sale conceptual class and Sale design class, creates a design with lower representational gap between software design and real domai
>---> The use case suggests the system events that are explicitly shown in system sequence diagrams, where the interaction between software objects whose names are sometimes inspired by the names of conceptual classes in the Domain Model, plus other classes of objects
Visibility: -Ability of one object to see or have have reference to another -Designs created for the system events (enterItem in sequence diagram) illustrate messages between objects, for a sender object to send a message to a receiver object, the sender must be visible to the receiver—the sender must have some kind of reference or pointer to the receiver object -Is one resource (such as an instance) within the scope of another? -Four common ways of achieving visibilty from object A to object B:
1) Attribute visibiilty: B is an attribute of A:
-Attribute visiblity from A to B exists when B is an attribute of A, is a relatively permanent visiblity because it persits as long as A and B exist
public class X
{
private:
Y name;
}
-The X instance may have attribute visibility to Y, or its instance name
-This visiblity is required to send the message such as
spec = name.getSomething()
2) Parameter visibility: B is a paramter of a method of A:
-B is passed as a paramter to a method of A
-Relatively temporary because it persists only within the scope of the method
public class X
{
private:
// ...
public:
void somemethod(Y name);
{
//can use name here
w = new W(name)
}
}
-Common to transform paramter visiblity into attribute visiblity, when X creates a new w then name becomes attribute visible to W
3) Local visiblilty: B is a (non-paramter) local object in a method of A
-Declared as a local object within a method of A
-Relatively temporary visibility because it perists only within the scope of the method
4) Global visiblity: B is some way globally visible
-A to B exists when B is global to A
-Least common in object-oriented systems
-In collaboration diagrams, visiblity is shown as <<associatoin>>, <<parameter>>, <<local>>, <<global>>
Design Class Diagrams (DCDs): -Many classes, methods and relationships may be sketched out very early in design by applying responsibility assignment patters, prior to the drawing of interaction diagrams -attributes lekhda aba name : Type garera lekhnu paryo, also methods lekhda methodName(para1 : trype) : returnType garera lekhna paryo -void ni lekhna painxa return type ma -… lekheko xa bhane members haru xan but mention gareko xaina, just empty xa bhane kei pani xaina bhanni bujhinxa
1. Identify software classes:
-Can be found by scanning all the iteraction diagrams listing the classes mentioned
-Draw a class diagram for these classes and include the attriutes previously identified in the Domain Model that are also used in the design
-Some concepts in the Domain Model are not present in the design, no need for the current iteration to represente them in software, in later iterations as new requirements and use cases are tackled, they may enter into the design
2. Add method names:
-Can also be identified by analyzing the interaction diagrams, if the message makeLineItem is sent to an instance of class Sale, then class Sale must define a makeLineItem method
-In general, the set of all messages sent to a class X across all interaction diagrams indicates the majority of methods that class X must define
-accessing methods are usually not shown (jasle attributes ko value return garxa)
3. Adding association and navigability:
-End end of an association is called a role, and in the DCDs the role may be decorated with navigability arrow, which is a property of the role that indicates that it is possible to navigate unidirectionally across the association from objets of the soruce to target class, implied visiblity- usually attriute visiblity
-Usually interpreted as the source class having an attribute that refers to an instance of the target class
4. Adding dependency relationships:
-To depict that one class has knowledge of another, implying non-attribute visiblity between classes
-Register software object receives a return object of type ProductSpeficiation from the speficiation message it sent to a ProductCatalog, so a dotted arrow from Register to ProductSpecification
5. Members visiblity:
-tei ho yesma ta aba + - # and ~ meaning same
6. What about inheritance and all that?
Mapping designs to code: -The creation of code in an object-oriented programming language -such as Java or C++ is not part of OOAD; it is an end goal where the artifacts created in Design Model provide some of the informatio necessary to generate the code -When the code in iteration N deviates from the design of iteration N (which it inevitably will), the final design based on the implementation can be input to the analysis and design models of iterations N+1 -It is desirable for the diagrams generated during design to be semi automatically updated to reflect changes in the subsequent coding work -Ideally should be done with a CASE tool that can read source code and automatically, generate, for example, class, and sequence diagrams, an aspect of reverse-engineering -the activity of gnerating diagrams from source or sometimes, executable code
-Creating class definiitions from DCDs:
1) Definiting a class with methods and simple attributes
-DCDs depict the class or interface name, superclasses, method signautres, and simple attributes of a class, sufficient to create a basic class definition in an OOP langugage
2) Adding refernece attributes:
-Is an attribute (data member) that refers to another complex object, not to a primite type such as String, Number and so on
-Are suggested by the associations and navigability in a class diagram
-Source dekhi target samma jada: private TargetType targetname;
3) Creating methods from iteraction diagrams:
-An iteraction diagram shows messages that are sent in response to a method invocation, sequence of these messages translates to a series of statements in the method defintiion
-(jasle message receive garexa tesko ma milayera method banauni)
4) Container/collection classes in code:
-Often necessary for an object to maintain visiblity to a group of other objects; the need for this is usually evident from the multiplicity value in a class diagram - it may be greater than one
-In OO programming, these relationships are often implmeneted with the introduction of a intermediate container or collection
5) Exceptions and error handling:
-An event that occurs during the execution of a program that disrupts the normal flow of instructions
-Precise is based on the preconditions, for which the operation will terminate normally, exception handling mechanism allows the procedure to raise an exception if this precondition is violated
-UML does not include an official solution to show exceptions thrown by an operation
1. UML allows the operation syntax to be any other language, such as Java so (member function jasari lekhni)
Object get(Key) throws Exception, FatalException
2. Exceptions caught are modelled as a kind of operation handling a signal (member jasari)
<<signal>> IOException()
<<signal>> SQLException()
3. Some allow one to specify (in a dialog box) the exceptions that an operation throws
(naya parition banauni, attributes ra methods ko jastai, tara exceptions name dini ani Exception ra FatalException lekhni)
-In the UML, an Exception is a specialization of a Signal, which is the specification of an asynchronous communication between objects. This means that in interaction diagrams, exceptions are illustrated as asynchronous messages.
-jastai euta lai executeQuery(...) bhanne message pathaye bhani return message <<exception>> SQLException() bhaner asynchronous messsage aauxa